tursodatabase/turso · critical

failed to generate random bytes

Error message

failed to generate random bytes

What it means

The VFS extension trait's default generate_random_number (extensions/core/src/vfs_modules.rs:28-32) fills an 8-byte buffer via getrandom::fill and unwraps it with expect("failed to generate random bytes"). getrandom only fails when the OS entropy source is unavailable or blocked - e.g. the getrandom(2) syscall is denied by a seccomp policy, or the platform has no usable entropy source. Any SQL needing engine randomness (random(), randomblob()) or a custom VFS that does not override this method will panic in that situation.

Source

Thrown at extensions/core/src/vfs_modules.rs:31

    pub builtin_vfs: *mut *const VfsImpl,
    pub builtin_vfs_count: i32,
}
unsafe impl Send for VfsInterface {}

pub trait VfsExtension: Default + Send + Sync {
    const NAME: &'static str;
    type File: VfsFile;
    fn open_file(&self, path: &str, flags: i32, direct: bool) -> ExtResult<Self::File>;
    fn remove_file(&self, path: &str) -> ExtResult<()>;
    fn run_once(&self) -> ExtResult<()> {
        Ok(())
    }
    fn close(&self, _file: Self::File) -> ExtResult<()> {
        Ok(())
    }
    fn generate_random_number(&self) -> i64 {
        let mut buf = [0u8; 8];
        getrandom::fill(&mut buf).expect("failed to generate random bytes");
        i64::from_ne_bytes(buf)
    }
    fn get_current_time(&self) -> String {
        chrono::Local::now().format("%Y-%m-%d %H:%M:%S").to_string()
    }
}

pub trait VfsFile: Send + Sync {
    fn lock(&mut self, _exclusive: bool) -> ExtResult<()> {
        Ok(())
    }
    fn unlock(&self) -> ExtResult<()> {
        Ok(())
    }
    fn read(&mut self, buf: BufferRef, offset: i64, cb: Callback) -> ExtResult<()>;
    fn write(&mut self, buf: BufferRef, offset: i64, cb: Callback) -> ExtResult<()>;
    fn sync(&self, cb: Callback) -> ExtResult<()>;
    fn truncate(&self, len: i64, cb: Callback) -> ExtResult<()>;

View on GitHub (pinned to 244cde92a7)

Solutions

1. Override generate_random_number in your Vfs implementation to source randomness from an API your environment permits (e.g. a pre-seeded RNG or platform API).
2. Fix the sandbox: add 'getrandom' to the seccomp allowlist (SECCOMP_RET_ALLOW) or relax the container security profile.
3. Ensure /dev/urandom exists and is readable in minimal containers.
4. Upgrade the getrandom crate dependency - newer versions cover more platforms and fallback paths.

Example fix

// before: default trait method panics in restricted sandbox
impl Vfs for MyVfs { /* generate_random_number not overridden */ }

// after: provide your own entropy source
impl Vfs for MyVfs {
    fn generate_random_number(&self) -> i64 {
        let mut buf = [0u8; 8];
        my_platform_fill(&mut buf); // e.g. pre-seeded RNG or host API
        i64::from_ne_bytes(buf)
    }
}

// Probe entropy availability once at startup, before SQL runs:
fn entropy_available() -> bool {
    let mut buf = [0u8; 8];
    getrandom::fill(&mut buf).is_ok()
}
// If false, install a VFS whose generate_random_number uses your own source
// and avoid random()/randomblob() in the schema.

Rust host: std::panic::catch_unwind around the first query that may touch randomness, then swap in a VFS override that does not call getrandom.

When it happens

Trigger: Using an extension VFS that inherits the default generate_random_number inside a sandbox that blocks the getrandom syscall (custom seccomp/AppArmor profile, gVisor, Kata), on embedded/WASI targets without an entropy source, or in minimal containers where the syscall or /dev/urandom is not available.

Common situations: Hand-rolled Docker seccomp profiles missing getrandom, gVisor/sandboxed runtimes, distroless or scratch containers with restricted devices, embedded deployments, CI in hardened sandboxes.

Related errors

• Transaction dropped unexpectedly.
• Invalid drop behavior: {value}
• Transaction dropped unexpectedly.
• Could not determine home directory
• Error setting Ctrl-C handler

AI-assisted analysis of tursodatabase/turso@244cde92a7 (2026-08-20). Data as JSON: /api/errors/075bfdb54235fe6b. Report an issue: GitHub.