Age | Commit message (Collapse) | Author |
|
- Make `hash_update_text` a method on `HashingMode<Digest>`,
`HashingMode<Digest>::update`.
|
|
- The implementation of `Clone` and `Eq` is the same as the
corresponding derived version. Use `derive` instead.
|
|
- `HashingMode` is mostly used by `HashedReader`.
- Move the `HashingMode` declaration and implementation from
`parse.rs` to `parse/hashed_reader.rs`.
|
|
- Previously, the code used an explicit state machine because it
predated the async fn support in rustc.
- This also fixes a bug where server and client lose sync if
the server returns an error.
|
|
- Previously, the code used an explicit state machine because it
predated the async fn support in rustc.
- This also fixes a bug where server and client lose sync if
PKDECRYPT returns an error.
|
|
|
|
|
|
- This is a verbatim copy, but unfortunately the copies diverged.
This commit aligns them again. Notably, this brings the following
fixes and improvements to armor::Reader:
- 7731320e: Once EOF is hit, don't poll reader again.
- 19a13f9b: Add tracing.
- a3c77e3f: Recycle buffers.
|
|
- To add a userid to a key, private key material is needed.
- State this explicitly in the error message.
- Fixes #952.
|
|
- Closes #947
|
|
Co-authored-by: Neal H. Walfield <neal@pep.foundation>.
|
|
|
|
|
|
- While we correctly ignored marker packets in the CertParser, we
did not ignore them in the CertValidator. This made sq inspect
complain about marker packets in certrings.
|
|
- When rejecting a bad critical notation, `Error::PolicyViolation`
was used incorrectly. The first field is the thing that is in
violation of the policy, not a description.
|
|
- When we reject a particular version of a packet, indicate what
version of the packet we rejected.
|
|
- For some packets we'd like to have different policies depending on
the version. This in particular applies to Signatures: by default
we want to reject v3 signatures, but accept v4 signatures.
- By default, reject v3 signatures as of 2007.
- Fixes: #945
|
|
- The description of the `Signature3` data structure was mostly a
copy and paste of the description of a `Signature4` data structure.
Unfortunately, some v4 specific information was not removed. Remove
it now.
|
|
|
|
- The test is supported to check that the default is used, so don't
override the default.
|
|
- To use a good list, we need to reject all options by default and
then only enable those on the good list.
- Add a mechanism to reject all options in a particular
category (hash algorithms, critical subpackets, asymmetric
algorithms, symmetric algorithms, AEAD algorithms, and packet
tags).
- See #941.
|
|
- It is sometimes useful to iterate over all variants of a
given enum.
- Add the `variants` method to AsymmetricAlgorithm
`PublicKeyAlgorithm`, `SymmetricAlgorithm`, `AEADAlgorithm`,
`CompressionAlgorithm`, `HashAlgorithm`, `SignatureType`,
`ReasonForRevocation`, `DataFormat`, `packet::Tag`, and
`SubpacketTag` to do this.
|
|
- 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!).
|
|
- The `tracer` macro declares a local macro, `t`, that can be used
to show additional tracing information.
- It is useful to just show that a function has been entered.
- Don't require that `t` be used.
|
|
|
|
- `HashAlgorithm`, `SubpacketTag`, `SymmetricAlgorithm`,
`AEADAlgorithm`, and `packet::Tag` implement `PartialEq`, `Eq`, and
`Copy`. Change `AsymmetricAlgorithm` to also implement those
traits.
- In addition to the aesthetic motivation, having the same interface
simplifies using all of these types with the same macro.
|
|
- Rename `--recipient-cert` to `--recipient-file`, `--signer-cert`
to `--signer-file`, and `--certificate` to `--certificate-file`.
- This rename makes it clearer that the argument is a file
containing a certificate.
- See #933.
|
|
- The argument to --signer-cert, --recipient-cert, and --certificate
is a certificate *file*, not a certificate. Update the description
and the documentation to reflect this.
|
|
- Rename `--recipient-key` to `--recipient-file`, `--signer-key` to
`--signer-file`, and `--revocation-key` to `--revocation-file`.
- This rename makes it clearer that the argument is a file.
- This paves the way for other ways to address keys.
- See #933.
|
|
- The argument to --signer-key, --recipient-key, and
--revocation-key is a key *file*, not a key. Update the description
and the documentation to reflect this.
|
|
|
|
The idna 0.2 to 0.3 changes are not relevant for how sequoia is using
idna. We have tested this and confirmed it in debian for
sequoia-openpgp 1.10.0-4.
|
|
- Sometimes it is useful to configure a `StandardPolicy` via a
configuration file.
- To avoid pulling in a number of additional dependencies, this is
implemented in a separate crate, `sequoia-policy-config`.
- Document its existence in the `StandardPolicy` documentation to
improve its discoverability.
- Fixes #941.
|
|
- Appeases the compiler that now complains about the unused result.
|
|
|
|
|
|
- Use Cargo.toml's rust-version field instead of a rust-toolchain
file. It is more flexible and does not prevent use of newer
compilers.
|
|
|
|
See https://doc.rust-lang.org/stable/clippy/configuration.html#specifying-the-minimum-supported-rust-version
|
|
Today, Debian testing (which will become the next Debian stable next
year) has a Rust toolchain version 1.60.0. As per Sequoia-PGP project
decision, our MSRV tracks what's going to be in the next Debian
stable.
Sponsored-by: pep.foundation
|
|
Sponsored-by: pep.foundation
|
|
Less code to maintain this way.
Sponsored-by: pep.foundation
|
|
More idiomatic this way.
Sponsored-by: pep.foundation
|
|
A char as a pattern makes it more explicit that we're matching a
single char.
Sponsored-by: pep.foundation
|
|
Sponsored-by: pep.foundation
|
|
Resolves #935 (in which Neal argues: "the programmer always has
to use a performance heuristic to determine whether to use
unwrap_or or unwrap_or_else. The heuristic should be as simple
as possible to reduce the programmer's cognitive burden and allow
them to concentrate on the task at hand. A simple heuristic is:
if the value is a literal, use unwrap_or otherwise use
unwrap_or_else. This is reasonable given that the cost of using
.unwrap_or_else(|| literal) instead of .unwrap_or(literal) is
effectively zero; it is never wrong from a performance
perspective to use unwrap_or_else instead of unwrap_or, but it
can be wrong to use unwrap_or instead of unwrap_or_else.")
|
|
- rpassword underwent some rework. The successor of
read_password_from_tty seems to be prompt_password, relevant commits
to rpassword:
- e6023757df00a67a1e16796db50c5ffad41b6268
- 2edf6cee07573ec4aa86531e6177ee90331d5c60
|
|
|
|
|
|
|