We actively support the following versions of dataprof:
| Version | Supported |
|---|---|
| 0.13.x | ✅ |
| 0.12.x | Security fixes |
| < 0.12 | ❌ |
We take the security of dataprof seriously. If you discover a security vulnerability, please report it responsibly.
- Do NOT create a public GitHub issue for security vulnerabilities
- Use GitHub's private security advisory feature to report issues
- Contact the maintainer through GitHub for urgent matters
When reporting a security vulnerability, please include:
- Description of the vulnerability
- Steps to reproduce the issue
- Potential impact and severity
- Any proposed fixes or mitigations
- Your contact information for follow-up
- Acknowledgment: We will acknowledge receipt within 48 hours
- Initial Assessment: We will provide assessment within 5 business days
- Status Updates: Progress updates every 7 days
- Resolution: We aim to resolve critical vulnerabilities within 30 days
- We will work with you to understand and resolve the issue quickly
- We will acknowledge your responsible disclosure publicly (with your permission)
- We will coordinate public disclosure timing with you
A weekly scheduled run, and every pull request that can affect the dependency
graph, audit it with cargo deny. Documentation-only pull requests are skipped
by the workflow's paths-ignore; they cannot reach Cargo.toml or Cargo.lock,
and the weekly run covers advisories published against dependencies that have
not changed. The audit runs twice:
cargo deny check # the default build
cargo deny --all-features check # every feature a user can enableThe second command exists because optional features are still published features. The database connectors pull in the whole SQLx client stack, and the async and Parquet features pull in a TLS stack; auditing only the default build reported green while a shipped feature graph carried an unreviewed advisory.
cargo audit reads its own configuration, so the same dispositions are recorded
in both deny.toml and .cargo/audit.toml. Adding an advisory to one without
the other leaves the second tool failing on a decision that has already been
made.
An advisory is only ignored when it has been read and judged not to apply, with the reasoning recorded here and a date at which it is re-examined. "It is inconvenient" is not a reason.
| Advisory | Crate | Disposition | Next review |
|---|---|---|---|
| RUSTSEC-2023-0071 | rsa 0.9.x |
Not applicable — see below | 2026-10-01 |
| RUSTSEC-2024-0436 | paste 1.0.15 |
Unmaintained, not a vulnerability; transitive via arrow-rs, no replacement available | 2026-10-01 |
| RUSTSEC-2026-0459 | libsqlite3-sys 0.30.1 |
Applies only to the sqlite feature with an untrusted database file and its -wal; no fixed version reachable through SQLx. See below |
2027-01-09 |
The advisory describes a timing sidechannel through which an attacker who can measure RSA private-key operations may recover the private key. It has no fixed release (RustCrypto/RSA#626).
dataprof reaches rsa only through sqlx-mysql, and only when the mysql
feature is enabled. That crate's entire use of it is in connection/auth.rs,
which imports RsaPublicKey and encrypts the password with OAEP during
sha256_password / caching_sha2_password authentication. It never constructs
an RsaPrivateKey, and never decrypts or signs.
So the advisory does not apply, for two independent reasons:
- No private-key operation exists to attack. dataprof is a MySQL client. It encrypts with the server's public key and holds no RSA private key of its own. The Marvin attack targets the party performing private-key operations — here, the MySQL server, whose RSA implementation is not this crate.
- The path is normally not taken at all. dataprof builds SQLx with
runtime-tokio-rustls, andencrypt_rsareturns before touching RSA when the connection is TLS.
This will be revisited if a fixed rsa ships, if SQLx drops the dependency, or
by 2026-10-01, whichever comes first.
SQLite before 3.54.0 can return uninitialized page-cache memory when it opens a
database file together with a -wal file whose page size differs from the
database's. A crafted pair of files can make ordinary queries return stale
bytes from the process's memory. libsqlite3-sys 0.30.1 bundles an affected
SQLite.
dataprof reaches it only through sqlx-sqlite: the sqlite feature, which is
not in the default build or the Python wheels, and the SQLx dev-dependency the
test suite builds. Unlike the advisory above, this one does apply in one case:
the SQLite connector opens the path it is given, so profiling a database file
that someone else wrote, with its -wal file beside it, is exposed. Until a
fix is reachable, do not profile an untrusted SQLite database that comes with
a -wal file.
The fix is libsqlite3-sys 0.39 (SQLite 3.54), and no SQLx release allows it:
sqlx-sqlite 0.9.0 requires libsqlite3-sys below 0.38. Linking the system
SQLite instead (SQLx's sqlite-unbundled) would not clear the audit, which
matches the crate version and not the features, and would make every build
with the sqlite feature need SQLite development files.
This will be revisited when a SQLx release allows libsqlite3-sys 0.39, or by
2027-01-09, whichever comes first.
When using dataprof:
- Keep your Rust toolchain updated
- Use the latest version of dataprof
- Be cautious when analyzing untrusted data files
- Review generated HTML reports before sharing them
- Use appropriate file permissions for sensitive data
dataprof includes several security considerations:
- Local file profiling makes no network connections; data is processed locally only
- Remote URL profiling (
async-streaming/parquet-asyncfeatures) and database profiling (postgres,mysql,sqlitefeatures) do make outbound network connections to the configured endpoints — review URLs and connection strings before profiling untrusted sources - HTML reports contain only analysis results, not raw data
- No persistent storage of analyzed data
- Memory-safe Rust implementation
Thank you for helping keep dataprof secure!