Age | Commit message (Collapse) | Author |
|
- This wasn't caught by the CI because none of the current backends
implement ElGamal.
- Fixes 2b4cfe58604202e0a2515cf7e3de72245d2c6633.
|
|
|
|
- When hashing text signatures in which `cr`, `lf`, and `crlf` are
normalized to `crlf`, if a `crlf` was split across two hash
updates, two `crlf`s would be hashed (one for the final `cr` in
the first update, and one for the leading `lf` in the second
update) instead of just one.
- Fix it.
- Fixes #960.
|
|
- RFC 4880 explicitly allows the use of v3 signatures, but adds:
> Implementations SHOULD accept V3 signatures. Implementations
> SHOULD generate V4 signatures.
- In practice, rpm-based distributions are generating v3 signatures,
and it will be awhile before we can actually stop supporting them.
https://bugzilla.redhat.com/show_bug.cgi?id=2141686#c20
- Add support for parsing, verifying, and serializing v3
signatures (but not v3 certificates, and not generating v3
signatures!).
|
|
|
|
- Previously, Sequoia refused to decrypt ESK-less SKESK4 using
S2K::Simple. This behavior was introduced very early on in
2a66a5aa. In the commit message, Kai wrote:
Also fixed a bug where ESK-less SKESK with simple S2K were
accepted despite the RFC forbidding it.
Which is an odd conclusion because the last paragraph of Section
5.3 is right next to the paragraph talking about having an ESK.
- In any case, I think this advice actually applies to both
variants. In both cases, CFB is used with an all zero IV, and then
a high-entropy session key (if ESK is present) or a high-entropy
first block (if we're using the SK to encrypt with a SEIPD
packet). If session-key reuse is a problem despite the plaintext
starting with a high-entropy string, then it is a problem in
either case.
- I see that as an advice for producers, I don't see any harm in
consuming and decrypting such an artifact.
- Fixes #796.
|
|
- We implement the cleartext signature framework by transforming the
message on the fly to a signed message, then using our parsing
framework as usual. However, we need to tweak the behavior
slightly.
- Notably, our CSF transformation yields just one OPS packet per
encountered 'Hash' algorithm header, and it cannot know how many
signatures are in fact following. Therefore, the message will not
be well-formed according to the grammar. But, since we created the
message structure during the transformation, we know it is good,
even if it is a little out of spec.
- This patch tweaks the streaming verifier's behavior to accommodate
this.
|
|
- Make sure that chunk sizes are between 64B and 4MiB.
- Fixes a DoS resulting from unconstrained, attacker-controlled heap
allocations.
- Fixes #738.
|
|
- Previously, the test parse::stream::test::decryptor broke if
Sequoia was built without compression support because they used an
compression container. Recreate the test vectors without
compression.
- Fixes #744.
|
|
Preserve the filters through CertParser::reset.
|
|
- These test vectors are generated by GnuPG (and the one with the
unclamped cv25519 secret by RNP).
|
|
|
|
- Update our MSRV to the one used in Debian bullseye, 1.48.0.
|
|
- See #335 and https://savannah.nongnu.org/bugs/index.php?60154
|
|
- Signatures with no layers generated panic at runtime as zeroth index
was not available.
- Make `Decryptor::from_buffered_reader` return Err when no layers are
available.
- Fixes #682.
|
|
- Implement verification of messages using the Cleartext Signature
Framework by detecting them in the armor reader, and transforming
them on the fly to inline signed messages.
- The transformation is not perfect. We need to synthesize
one-pass-signatures, but we only know the hash algorithm(s) used.
Luckily, this is the only information the packet parser needs.
- We only enable the transformation when using stream::Verifier.
The transformation is transparent to the caller. Currently, there
is no way to disable this. In the next major revision, we may add
ways to control this behavior.
- Fixes #151.
|
|
- It is possible for a primary key to also be a subkey.
- Correctly handle that case.
- In particular, don't merge Public Key packets with Public Subkey
packets, etc.
|
|
- If no data has been read, that may indicate an error. In this
case, even requesting no data may fail.
|
|
- When two serialized messages in the for-each-artifact test differ,
print more helpful debugging output.
|
|
- Fixes #610.
|
|
- Fixes #618.
|
|
|
|
|
|
- Change `Cert::into_packets` to return the underlying packets.
That is don't drop secret key material like `Cert::serialize`
does.
|
|
- See #480.
|
|
This runs into surprising interactions when trying to build member
packages with other than default feature set.
See https://gitlab.com/sequoia-pgp/sequoia/-/issues/575 for more info.
|
|
|
|
- This is only used to communicate with the GnuPG agent, so it
should not be in the openpgp crate.
|
|
- Fixes #539.
|
|
- Fixes #531.
|
|
|
|
- Previously, a signature packet with a malformed embedded signature
would break the parsing, because the embedded signature is turned
into an unknown packet, hence `Signature::from_reader` returns
`Error::InvalidOperation` and so does `SubpacketArea::parse`.
Errors from that function are handled using php_try!, but that did
not make the packet turn into an unknown packet, but terminated
the parsing.
- Looking at `Subpacket::parse` revealed that there are more errors
that would terminate parsing in the outlined way, notably
`Error::MalformedPacket`, but there may be others.
- Fix this by tweaking php_try! to return unknown packets on any
`openpgp::Error`.
|
|
- See #471.
|
|
- Fixes #495.
|
|
- Add a new constructor that takes headers. This allows us to make
the header argument polymorphic.
|
|
This reverts commit 2e1eec5fe4157a391a13554ff7df3075cfe043cc.
|
|
- We don't throw away components with no (valid) self signatures.
- Add a test demonstrating this.
- Correct the documentation.
|
|
- This avoids the partial implementation imitating
std::option::Option, replacing it with std::result::Result.
- As a benefit, std::result::Result is in the prelude, simplifying a
lot of parsing loops.
|
|
- Writers should be finalized, builders should be built.
|
|
- Preferences should be implemented for ValidComponentAmalgamation
and ValidCert, not ValidComponentAmalgamation and
ValidKeyAmalgamation.
- Adjust the Preferences trait since ValidCert doesn't implement
ValidAmalgamation.
|
|
|
|
|
|
- If we strip the opaque encoding marker, preserve any leading
zeros.
- Fixes #439.
|
|
- Use the anyhow crate instead of failure to implement the dynamic
side of our error handling. anyhow::Error derefs to dyn
std::error::Error, allowing better interoperability with other
stdlib-based error handling libraries.
- Fixes #444.
|
|
- Add two new traits: `Marshal` and `MarshalInto`.
- Implement them instead of `Serialize` and `SerializeInto`.
- Only implement `Serialize` and `SerializeInto` for data structures
that are normally exported.
- This should prevent users from accidentally serializing a bare
signature (`Signature`) when they meant to serialize a signature
packet (`Packet`), for instance.
- Fixes #368.
|
|
- This test demonstrates that we consider binding signatures valid
even if the primary key is not marked as certification-capable.
- Fixes #321.
|
|
- Now that we have the policy trait, we can enable weak hash
algorithms. Enable MD5 and RipeMD160.
- Add test vectors.
|
|
- This patch series adds methods to query key constraints and other
key-related signature subpackets to trait Amalgamation.
Key-related subpackets are relevant to all components. Recall
that primary key constraints may be expressed on userid binding
signatures, and that userid components may be stripped off.
- We do the same for the key holder's preference packets. These
subpackets are not relevant to subkeys, therefore we introduced a
new trait Preferences that is implemented for valid componentsand
primary keys.
- Add the original test case from the bug report.
- Fixes #215.
|
|
- Move the autocrypt-related functionality to a new crate.
- Fixes #424.
|
|
- Previously, signatures following an unknown packet (like a version
3 signature) were attributed to the unknown component. To fix
that, try to reorder all signatures on unknown components. If we
fail, we put them back where we found them, assuming they are at
the correct location on an component unknown to us.
- Also split signatures of unknown components.
- Add test case.
|