Skip to content

Security: geoff1111/jsqlite

Security

SECURITY.md

Security policy

Supported configuration

Production deployments should use make release, leave DEBUG_API=0, and keep the jim() SQL function disabled unless trusted SQL genuinely requires it. Prefer safe mode for databases or SQL supplied by less-trusted code. Loadable SQLite extensions are native code and must be treated as fully trusted.

Security-sensitive features

  • jim() can invoke Jim Tcl commands and is opt-in.
  • deserialize replaces the current database image and is disabled by safe mode or nodeserialize.
  • -extension loads native code and is rejected by safe mode.
  • do accepts multiple SQL statements and performs no parameter binding; untrusted values must use query parameters.
  • Safe mode installs a restrictive SQLite authorizer, but it is still prudent to apply OS-level file and process isolation around untrusted workloads.

Validation before release

Run at least:

make clean release
make test
N=100 make test-repeat
make coverage
make jim-sanitize
make sanitize
make test-sanitize
make memcheck

Fuzz targets are additional crash-resistance checks:

make fuzz-all
make fuzz-repeat

Reporting

Security reports should include the jsqlite revision, Jim Tcl revision, SQLite version, compiler and flags, operating system, a minimal reproducer, and sanitizer or Valgrind output where available.

There aren't any published security advisories