This project might be open to known security vulnerabilities, which can be prevented by tightening the version range of affected dependencies. Find detailed information at the bottom.
svc-authn(13 total, 6 outdated, 2 possibly insecure)
| Crate | Required | Latest | Status |
|---|---|---|---|
| atty | ^0.2 | 0.2.14 | up to date |
| chrono ⚠️ | ^0.4 | 0.4.38 | maybe insecure |
| config | ^0.13 | 0.14.0 | out of date |
| diesel ⚠️ | ^1 | 2.1.6 | out of date |
| dirs | ^5 | 5.0.1 | up to date |
| http | ^0.2 | 1.1.0 | out of date |
| jsonwebtoken | ^7 | 9.3.0 | out of date |
| serde | ^1 | 1.0.200 | up to date |
| serde_derive | ^1 | 1.0.200 | up to date |
| serde_json | ^1 | 1.0.116 | up to date |
| sqlx | ^0.6 | 0.7.4 | out of date |
| structopt | ^0.3 | 0.3.26 | up to date |
| toml | ^0.7 | 0.8.12 | out of date |
chrono: Potential segfault in `localtime_r` invocationsUnix-like operating systems may segfault due to dereferencing a dangling pointer in specific circumstances. This requires an environment variable to be set in a different thread than the affected functions. This may occur without the user's knowledge, notably in a third-party library.
No workarounds are known.
diesel: Fix a use-after-free bug in diesels Sqlite backendWe've misused sqlite3_column_name. The
SQLite documentation
states that the following:
The returned string pointer is valid until either the prepared statement is destroyed by sqlite3_finalize() or until the statement is automatically reprepared by the first call to sqlite3_step() for a particular run or until the next call to sqlite3_column_name() or sqlite3_column_name16() on the same column.
As part of our query_by_name infrastructure we've first received all
field names for the prepared statement and stored them as string slices
for later use. After that we called sqlite3_step() for the first time,
which invalids the pointer and therefore the stored string slice.