0.17.x does not appear in this table because it was never published: 0.17.0 was prepared but not released, and its changes ship in 0.18.0 (see the 0.18.0 entry in CHANGELOG.md). On crates.io, 0.18.0 follows 0.16.0.

If you discover a security vulnerability in quack-rs, please report it responsibly.

Do NOT open a public GitHub issue for security vulnerabilities.

Instead, please use GitHub's private vulnerability reporting feature on this repository. Alternatively, email tomf@tomtomtech.net with the subject line [quack-rs security].

• A description of the vulnerability
• Steps to reproduce (minimal test case preferred)
• The impact (e.g., memory safety, information disclosure, denial of service)
• The affected version(s)

• Acknowledgment: Within 48 hours of report
• Assessment: Within 7 days
• Fix: Depends on severity; critical issues are prioritized

This security policy covers:

• Memory safety issues in unsafe code (use-after-free, double-free, buffer overflow)
• Undefined behavior in FFI callbacks
• Panics that escape an FFI boundary (since Rust 1.81 an unwind out of an extern "C" function aborts the process instead of being undefined behaviour, which still takes down the host's DuckDB session)
• Information disclosure through uninitialized memory

This policy does not cover:

• Bugs in DuckDB itself (report those to DuckDB)
• Bugs in libduckdb-sys bindings (report to duckdb-rs)
• Logic errors in extension code built with quack-rs (those are the extension author's responsibility)

quack-rs is designed with safety as a primary concern:

1. #![deny(unsafe_op_in_unsafe_fn)] in src/lib.rs and unsafe_op_in_unsafe_fn = "deny" in Cargo.toml: every unsafe operation needs an explicit unsafe block, even inside unsafe fn. Each unsafe fn documents its caller obligations under # Safety, and every unsafe block in library code carries a // SAFETY: comment, including a block inside an unsafe fn that only forwards that function's contract (the comment then names the clause it relies on). clippy::undocumented_unsafe_blocks is enabled and CI runs clippy with -D warnings, so an unannotated block fails CI. The convention is set out in the crate docs, src/lib.rs.
2. No panics across FFI: The entry points generated by entry_point! / entry_point_v2!, callbacks defined with the *_callback! macros (src/callback.rs), the closure-based builders and FfiState<T>'s callbacks run user code inside catch_unwind and report a panic as a SQL error. A raw unsafe extern "C" fn that an extension author passes to a builder is installed as written, with no guard; the author must use the matching macro or wrap the body in callback::catch_ffi_panic. The release profile therefore sets panic = "unwind", not abort: under panic = "abort" a panic aborts the process before catch_unwind can run, which disables the crate's entire panic-containment mechanism. validate_release_profile rejects abort outright, and the generated scaffold never emits it.
3. Double-free prevention: FfiState<T>::destroy_callback clears each state's tag before dropping it.
4. Boolean UB prevention: VectorReader::read_bool reads as u8 != 0, never transmutes to bool.
5. RAII for DuckDB handles: LogicalType ensures duckdb_destroy_logical_type is always called.
6. Credential protection: SecretEntry redacts field values in Debug/Display output and zeroizes all sensitive data on Drop using write_volatile.
7. TLS hardening: TlsConfigProvider has no default minimum version — min_tls_version is a required method, so every provider states one — and audit_tls_provider() flags certificate-validation bypass (CWE-295) and deprecated protocol versions (CWE-327).
8. Structured warnings: WarningCollector provides thread-safe, CWE-annotated security warning collection for extensions.