Loading
Commits on Source 67
-
Neal H. Walfield authored
-
Neal H. Walfield authored
-
Neal H. Walfield authored
- In the rust-crypto backend, we need to expand the blowfish key from 16 bytes to 56 bytes. We do this on the heap and then forget to clear the memory. - Do it on the stack instead, which we do clear. - Fixes #1213. Reported-by: GHORAB Djamel Eddine Hakim -
Neal H. Walfield authored
- When encrypting data using Window CNG, the provided data must be provided in a block-sized buffer. - If the caller provides a partial block of data, we copy the data to an appropriately sized buffer that is allocated on the heap. This leaks the plaintext to the heap. - Use a `Protected` buffer instead of a `Vec`. `Protected` wipes the memory when it is dropped. - Fixes #1215. Reported-by: GHORAB Djamel Eddine Hakim -
Neal H. Walfield authored
- If `zeroize` is included in the dependency tree, then `win-crypto-ng` will use it to clear buffers that contain secrets. Other dependencies should pull in `zeroize`, but we should do so explicitly to be doubly sure that it is actually available. - Fixes #1216. Reported-by: GHORAB Djamel Eddine Hakim -
Neal H. Walfield authored
- When decrypting data using the rust crypto backend, be sure to clear a buffer containing plaintext when it is dropped. - Fixes #1226. Reported-by: GHORAB Djamel Eddine Hakim -
Neal H. Walfield authored
- Improve `Decryptor` to clear copies of the plaintext when dropped. - Fixes #1226. Reported-by: GHORAB Djamel Eddine Hakim
-
Neal H. Walfield authored
- Currently, the secret leak detector scans the process's memory for leaked secrets after the test has run. This is comprehensive as it scans not only memory that was allocated on the heap and later deallocated, but also memory that wasn't freed and the stack. A disadvantage is that it provides little information about where in the code a leak occured, which makes identifying leaks difficult. - Extend the secret leak detector to check if a deallocation includes the secret. If so, save and later print a backtrace. This significantly simplifies debugging as we can often see what drop handler freed the memory and thus know what data structure is leaking the secret. -
Neal H. Walfield authored
- Currently, we store the authentication cookie in a `Vec`. A `Vec`'s content isn't protected at rest, and when dropped, it will live on in the heap. - Store it in an `Encrypted` instead, which encrypts the content at rest, and scrubs it when dropped. - Fixes #1209. Reported-by: GHORAB Djamel Eddine Hakim -
- Parsing invalid octal values like `\400` should not result in a value but in a syntax error. - Fix it and add a test. - Fixes #1222. Reported-by: GHORAB Djamel Eddine Hakim -
While reading the documentation it wasn't clear what to expect from the return value without checking the code (and knowing what `std::mem::replace` returns). Explicitly note the old values are returned on the various `set_*()` functions.
-
Neal H. Walfield authored
- The Argon2-based `S2K::derive_key` path allocates its working memory through an internal `Blocks` helper, which wraps a `*mut argon2::Block` obtained via `alloc_zeroed`. After Argon2 finishes, the temporary `Blocks` instance is dropped, but its `Drop` implementation simply hands the pointer back to the global allocator without overwriting the contents. This leaves the entire Argon2 memory matrix - including the lane blocks that determine the derived session key - sitting in heap pages until the allocator decides to reuse them. - Wipe the memory before deallocating it. - Fixes #1211 Reported-by: GHORAB Djamel Eddine Hakim -
Neal H. Walfield authored
-
Neal H. Walfield authored
- See #1213 Co-authored-by: GHORAB Djamel Eddine Hakim
-
Neal H. Walfield authored
- Version `0.1.5` was yanked.
-
-
Neal H. Walfield authored
-
- `Encrypted::map`, `Password::map`, `Unencrypted::map`: `FnMut` to `FnOnce`, as the callback is invoked exactly once. - `ValidBindingSignature::map`: `Fn` to `FnMut`, as the calls are sequential. - These are non-breaking changes due to the `Fn: FnMut: FnOnce` hierarchy. - Fixes #1234. -
Some of the VerificationError variants have an "error" field that allows to track the error chain. To do this, however, requires manual destructuring of each variant to extract the field. This instead implements std::error::Error::source for VerificationError, so one can consolidate the matching expressions, something like: if let Some(source) = verification_error.source() { let causes = anyhow::Chain::new(source) .skip(1) .map(|cause| format!("\tbecause: {cause}")) .collect::<Vec<_>>() .join("\n"); format!("{verification_error}:\n{causes}") } else { verification_error.to_string() } Signed-off-by:Daiki Ueno <dueno@redhat.com>
-
Neal H. Walfield authored
-
Neal H. Walfield authored
- The registry is no longer hosted by jampot. Instead of hard coding the host, use the alias registry.sequoia-pgp.org. -
Neal H. Walfield authored
- This update fixes a build issue with bindgen and clang. - See nettle-sys@c0ddac76
-
Neal H. Walfield authored
-
Neal H. Walfield authored
- If an RSA private key was generated according to FIPS 186-5 (like Botan), then to derive `e` from the private key parameters, we need to use `e*d = 1 mod (lcm(p-1, q-1))`, not `e*d = 1 mod ((p-1) * (q-1))`. Note: if this is not the case, then using the `lcm` instead of `(p-1) * (q-1)` should have no effect. See https://github.com/randombit/botan/issues/5524 Reviewed-by:Clemens Lang <cllang@redhat.com>
-
Neal H. Walfield authored
- `rand` has a security vulnerability. See the advisory at: https://rustsec.org/advisories/RUSTSEC-2026-0097.html -
This commit also drops lint-level configuration applied via RUSTFLAGS from .cargo/config.toml that appears to have previously accidentally overridden settings applied in CI via command-line arguments.
-
The `resolver = "3"` setting is available since Rust 1.84 and this project has an MSRV of 1.85, so there is no reason not to use it. Using this setting instead of the previous workaround of setting `incompatible-rust-version = "fallback"` in .cargo/config.toml should be more robust (i.e. running "cargo update" with an old version of cargo will now raise an error instead of silently ignoring the setting).
-
Fixes an error for the "clippy::unused_io_amount" lint.
-
Calling `drop()` for a value of a type that does not implement the `Drop` trait is a noop (except for extending the value's lifetime). Fixes a "suspicious" error for the "clippy::drop_non_drop" lint.
-
Fixes "suspicious" errors for the "clippy::empty_line_after_doc_comments" lint.
-
The loops that never loop and an assert for only one result can be replaced with a Tryinto for an exactly-one-sized array. The if-let statement with two "unreachable!" statements can be replaced with one let else statement and only one "unreachable!" statement. Avoids two errors for the "clippy::never_loop" lint.
-
This adapts test code that previously didn't handle partial reads and writes by either 1. explicitly ignoring the number of read / written bytes, 2. switching from Writer::write to Writer::write_all, or 3. explicitly checking the return value in case its known. Fixes various errors raised for the "clippy::unused_io_amount" lint.
-
Calling `Lines::filter_map` can loop forever if reading from the underlying file fails. It looks like calling `Lines::map_while` was the intention here, which has the same effect of "only return Ok results" but it stops producing elements on the first error instead of entering an endless loop.
-
This always-false boolean expression for an if statement condition is intended to "comment out" code but have it still get checked. Silences an "clippy::overly_complex_bool_expr" error.
-
- Add the cx448 crate as a dependency for the RustCrypto and Windows CNG backends. - The Windows CNG backend uses cx448 as a pure-Rust fallback, similar to how it uses ed25519-dalek for Ed25519. - Fix type inference ambiguities in the statistics example and doc-tests caused by the new `serde_json` dependency, which was pulled in via `cx448`, the new direct dependency. -
- Extend signature_roundtrip to verify that a wrong digest is rejected for all tested algorithm/version combinations. -
Fabio Valentini authored
This warning was enabled by default in Rust 1.89.
-
Fabio Valentini authored
-
Fabio Valentini authored
-
Fabio Valentini authored
Fixes an "unused_parens" compiler warning.
-
Fabio Valentini authored
Using the "vec!" macro instead of initializing an empty Vec and pushing multiple times is more efficient and also less noisy. This fixes 20+ warnings for the "clippy::vec_init_then_push" lint.
-
Fabio Valentini authored
This fixes 11 warnings raised for the "clippy::expect_fun_call" lint and avoids string formatting in the happy path by replacing "Result::expect" with "Result::unwrap_or_else" with a closure that does not get called on the happy path.
-
Fabio Valentini authored
This fixes a "clippy::missing_const_for_thread_local" warning. Marking the thread-local initializer as "const" apparently allows the compiler to generate more efficient code in some cases.
-
Fabio Valentini authored
Fixes a warning for the "clippy::cmp_owned" lint.
-
Fabio Valentini authored
The "format!" macro already uses the Display trait impl for its arguments, calling "to_string()" on the value first unnecessarily allocates a separate String. Fixes a warning for the "clippy::to_string_in_format_args" lint.
-
Fabio Valentini authored
Calling "last" iterates through the entire iterator until it encounters the last element. Calling "next_back" on a double-ended iterator instead is constant-time. Fixes four warnings for the "clippy::double_ended_iterator_last" lint.
-
Fabio Valentini authored
Fixes a warning for the "clippy::format_in_format_args" lint.
-
Fabio Valentini authored
Fixes one warning for the "clippy::useless_vec" lint.
-
Fabio Valentini authored
Fixes a warning for the "clippy::manual_contains" lint.
-
Fabio Valentini authored
-
Fabio Valentini authored
Fixes a warning for the "clippy::slow_vector_initialization" lint.
-
Fabio Valentini authored
The "Encoder" enum variants had a very large size difference (even larger than the 512 byte difference set in the clippy configuration): The Encoder::Cert variant was 8 bytes, whereas the Encoder::TSK variant was ~840 bytes large. This causes a lot of stack space to be wasted in functions that deal with values of this type. Wrapping the "TSK" variant contents in a Box to heap-allocate it should reduce the overall size of the enum from ~840 to 8 bytes.
-
Fabio Valentini authored
The Any::downcast trait method returns the original value on error on purpose, so the Err variant being large is expected. Silences one warning for the "clippy::result_large_err" lint.
-
Fabio Valentini authored
-
`cargo test fmt --package sequoia-openpgp`.
-
This entry was added recently to improve the codebase, however it prevented fuzz test targets from running. I've removed it. There may be a better fix. FYI the fuzz tests can be run as follows: ``` cargo fuzz list cargo fuzz run cert_from_bytes fuzz/corpus/cert_from_bytes -- -max_total_time=10 ```
-
-
Add a new fuzz target for packet-level parsing, together with a small structured seed corpus and a generator for maintaining it. The new target (`key_packet_from_bytes`) exercises `Packet::from_bytes` using arbitrary inputs, seeded with valid key-packet encodings. If a packet parses as a key packet, it is also serialized and reparsed to exercise key serialization paths. Add a small example (`generate_key_seeds`) that generates structured seed inputs using `CertBuilder`. This writes: - certificate inputs for `fuzz/corpus/cert_from_bytes/` - key-packet inputs for `fuzz/corpus/key_packet_from_bytes/` These corpora are intentionally small and consist of valid OpenPGP objects, providing useful starting points for fuzzing. Also add a `fuzz/README.md` documenting how to run fuzz targets and regenerate seed corpora. This improves fuzz coverage of packet parsing and key serialization, and provides a simple workflow for extending fuzz inputs.
-
`RawCertParser` is a low-level OpenPGP certificate parser. A specially formed certificate causes the `RawCertParser` attempt to read beyond the end of an array, which results in a panic. As many application using this library process certificates received from untrusted sources like email and key servers, an attacker can exploit the vulnerability over the network. As creating a malformed certificate is straightforward, the attack's complexity is low. Fixes #1244. Co-authored-by:
Neal H. Walfield <neal@sequoia-pgp.org>.> Reported-by:
Julian Harty <julianharty@gmail.com>
-
RawCertParser could panic when given malformed input consisting of a valid certificate prefix followed by arbitrary trailing data. Specifically, the parser assumed that previously "processed" bytes could always be consumed: expect("just read it") However, for certain inputs the parser's internal accounting diverged from the underlying reader, causing data_consume_hard() to return an UnexpectedEof error and triggering a panic. This was fixed in the previous commit. This commit adds some fuzz testing: - Added `rawcert_from_bytes` fuzz target to help exercise RawCertParser. - Add regression input and valid certificate seeds to the fuzz corpus. This aims to ensure ongoing coverage of the failure mode and prevents regressions. See #1244. -
Neal H. Walfield authored
Issue #1244 revealed an issue with the `RawCertParser` (see previous commit). Add an equivalent unit test for `CertParser`, which demonstrates that the issue does not impact the `RawCertParser`, and that the behavior of the `RawCertParser` and `CertParser` are identical. See #1244.
-
Neal H. Walfield authored
OpenPGP supports nested signatures. Normally only a single level of nesting is used, however, an attacker could create a deeply nested data structure. When Sequoia would parse such a signature, it would recurse, which could exhaust the stack, and cause the program to crash. We've mitigated this vulnerability by changing Sequoia to reject signatures that have more than a single level of nesting. Nested signatures are used in conjunction with subkey binding signatures. To associate a subkey with a certificate, the primary key issues a so-called subkey binding signature over the primary key and the subkey. This is a statement by the primary key that the subkey is part of the certificate. To prevent an attacker from claiming a subkey and any signatures it issued, signing-capable subkeys also issue a so-called primary key binding signature. A primary key binding signature is a statement by the subkey that says what certificate it is a part of. Unless the attacker has the subkey's secret key material, it can't forge a primary key binding signature and thus can't claim the subkey. Whereas the subkey binding signature is stored as a top-level packet in a certificate, the primary key binding signature is nested in the subkey binding signature as an embedded signature. As an embedded signature is just a normal signature, a subkey binding signature can also contain an embedded signature. An attacker can use this to create a deeply nested signature. For details, see Sections 5.2.3.34, 5.2.1.8 and 5.2.1.9 of RFC 9580: https://www.rfc-editor.org/rfc/rfc9580.html#section-5.2.3.34 https://www.rfc-editor.org/rfc/rfc9580.html#section-5.2.1.8 https://www.rfc-editor.org/rfc/rfc9580.html#section-5.2.1.9 When Sequoia would parse an embedded signature, it would recurse and parse it like a normal signature. An attacker could create a signature that contains thousands of nested signatures. When Sequoia parsed such a signature, it could exhaust the stack, which would result in the program crashing. Fix this by rejecting embedded signatures that contain an embedded signature. This vulnerability is present since the first release of sequoia-openpgp. Reported-by: Malte Fries -
Neal H. Walfield authored
Some old v4 certificates (ca. 1998) used v3 signatures for binding signatures. Since v3 signatures do not have signature subpackets, they do not include the key flags field. In such cases, an implementation would infer the key capabilities from the key's public key algorithm. The way that Sequoia infers the key flags can lead to a key flag confusion attack in which Sequoia does not check that a signing subkey has a back signature, but should. This allows an attacker to claim a subkey and any signatures it issued. The key flags confusion arises as follows. Sequoia exposes the key flags via two methods: [`SubpacketAreas::key_flags`] and [`ValidKeyAmalgamation::key_flags`]. The former method returns the raw key flags. It can't infer key flags based on the key's public key algorithm, as that information is not available. The latter method, `ValidKeyAmalgamation::key_flags`, has both the binding signature and the key and infers the key flags from key public key algorithm if the key flags subpacket is absent. This means that two different views of the key flags may be inadvertently used when making a security decision. [`SubpacketAreas::key_flags`]: https://docs.rs/sequoia-openpgp/latest/sequoia_openpgp/packet/signature/subpacket/struct.SubpacketAreas.html#method.key_flags [`ValidKeyAmalgamation::key_flags`]: https://docs.rs/sequoia-openpgp/latest/sequoia_openpgp/cert/amalgamation/key/struct.ValidKeyAmalgamation.html#method.key_flags When checking whether a subkey belongs to a certificate, Sequoia used `SubpacketAreas::key_flags` to get the key flags. If the key flags were not set, then it would not check for a valid back signature. When verifying a signature over data, it would use `ValidKeyAmalgamation::key_flags` (via `for_signing`) to check if the signing key was signing capable. In this case, if the key flags were not set, the key flags would be inferred from the key's public key algorithm. This allows an attacker to circumvent the back signature check by binding a subkey to their certificate and not setting its key flags in the binding signature. https://gitlab.com/sequoia-pgp/sequoia/-/blob/cd6116b2/openpgp/src/cert/bundle.rs#L375 https://gitlab.com/sequoia-pgp/sequoia/-/blob/cd6116b2/openpgp/src/parse/stream.rs#L2899 This change removes the code that infers the key flags from the public key algorithm. That code was introduced in July 2023, which was first released in `sequoia-openpgp` 1.17.0. 9e48a064 Reported-by: arccode -
Neal H. Walfield authored
-
Neal H. Walfield authored
There's a new version of `lalrpop`. The new version remains compatible with the subset of the API that we use. Loosen the dependency requirements to also allow it. Don't actually upgrade, as it requires a newer version of `rustc` than our MSRV.
-
Neal H. Walfield authored
-
Neal H. Walfield authored