| Age | Commit message (Collapse) | Author |
|---|
|
|
|
- For historical reasons, if the S2K usage octet is not a known S2K
mechanism, the octet denotes a symmetric algorithm used to
encrypt the key material with. In this case, the symmetric key is
the MD5 sum over the password. See section 5.5.3. Secret-Key
Packet Formats of RFC4880.While this is obviously not a great
choice, it is no worse than `S2K::Simple { hash: MD5 }`, since
it is equivalent to that.
- Model this by adding a new S2K variant.
- Notably, this fixes handling of packets with unknown S2K
mechanisms. Under the model of RFC4880, which we implement, any
unknown S2K mechanism is an implicit S2K, where the usage octet
denotes an unsupported symmetric algorithm. Using this will fail,
but we now can parse and serialize it correctly, and with them the
secret key packets they come in.
- Fixes #1095.
|
|
|
|
- There is no `Curve::Private`.
|
|
- Similar to Signature::verify, but doesn't constrain to document
signatures. This allows for faster verification of third-party
signatures on certs, taking advantage of the fact that we computed
the digest during certificate canonicalization.
|
|
- We have done the hashing, and the cert structure provides enough
context to do the verification without doing the hashing again.
|
|
|
|
- Introduce a new function, Signature::verify_digest_internal, that
only uses concrete types to reduce monomorphization, handles the
stashed computed digest, and takes an optionally owned signature
digest.
|
|
- During parsing, we parse the primary key. Keep that around for
later instead of caching only the fingerprint. Simplify accessors
accordingly.
|
|
|
|
|
|
- Notably, this is done during certificate canonicalization. This
is expensive as-is, let's keep the allocator out of it.
|
|
- Notably, this is done during certificate canonicalization. This
is expensive as-is, let's keep the allocator out of it.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
- If we can't open the socket, include the socket's file name as
context.
|
|
- To simplify debugging client-server interactions, add tracing
callbacks to `Assuan`.
|
|
- The Chameleon copied and improved `Client::send_simple`. Update
the copy here. See:
https://gitlab.com/sequoia-pgp/sequoia-chameleon-gnupg/-/blob/70802790d7d95c0084a8fea71a0836b3efc39910/src/agent.rs#L182
|
|
- If the server exits, we set the connection's state to
`WriteState::Dead`.
- When sending a message, don't panic if the connection's state is
`WriteState::Dead`. Instead, return an error message.
|
|
- dvzrv and wiktor left the project, rescind their authorizations.
- See https://gitlab.com/sequoia-pgp/sequoia-web/-/merge_requests/47 .
|
|
|
|
- Fixes #1091.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
- OpenPGP uses the uncompressed representation. Previously, the
OpenSSL backend used the compressed representation by mistake.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
- Keep `anyhow` at 1.0.76; the latest version (1.0.80) still exhibits
the performance problem on Windows.
- See https://github.com/dtolnay/anyhow/issues/347 .
|
|
- According to the documentation for [`TcpListener::from_std`] the
passed socket must be in non-blocking mode:
> The caller is responsible for ensuring that the listener is in
> non-blocking mode. Otherwise all I/O operations on the listener
> will block the thread, which will cause unexpected
> behavior. Non-blocking mode can be set using set_nonblocking.
[`TcpListener::from_std`]: https://docs.rs/tokio/1.36.0/tokio/net/struct.TcpListener.html
- Make sure that is the case for any socket we pass to
`TcpListener::from_std`.
|
|
- Asymmetric::x25519_generate_key generates an X25519 key. Clamping
is not necessary here: X25519 mandates implicit clamping when
decrypting.
|
|
- Move common code into a common frontend function.
|
|
- Fixes #1087.
|
|
|
|
|
|
|
|
Signed-off-by: Luca Saiu <positron@pep-project.org>
|
|
|
