Age | Commit message (Collapse) | Author |
|
- According to the `ahash` `README`, it performs better than
`xxhash`.
- `ahash` is also used by some of our dependencies, `xxhash` isn't.
- Fixes #1074.
|
|
- Change `UserID::from_address` to wrap a bare address in angle
brackets. That is, change `UserID::from_address` so that
`UserID::from_address(None, None, "alice@example.org")` maps to
`<alice@example.org>` not `alice@example.org`. This has the
advantage that the standard regular expression for scoping CAs can
match bare email addresses, see:
https://docs.sequoia-pgp.org/sequoia_openpgp/regex/index.html#caveat-emptor
- Fixes #1076.
|
|
- Add `UserIDAmalgamation::valid_third_party_revocations_by_key` and
`KeyAmalgamation::valid_third_party_revocations_by_key`, which
return third-party revocations that were made by a particular key at
a particular time, i.e., they also verify that the signatures are
valid.
|
|
- Add `UserIDAmalgamation::valid_certifications_by_key` and
`KeyAmalgamation::valid_certifications_by_key`, which return
third-party certifications that were made by a particular key at a
particular time, i.e., they also verify that the signatures are
valid.
- Add `UserIDAmalgamation::active_certifications_by_key` and
`KeyAmalgamation::active_certifications_by_key`, which return the
active certifications made by a particular key at a particular time.
|
|
- Add `ComponentAmalgamation::certifications_by_key`, which returns
third-party certifications that appear to be made by a particular
key. Specifically, this function only checks that the
certificates include a matching issuer or issuer fingerprint
subpacket; the certifications are not verified.
|
|
|
|
- Also, disable the default features and enable only what we need.
|
|
- Previously, all optional dependencies created implicit features.
This is unnecessary in our case, and may cause friction for
packagers. See
https://doc.rust-lang.org/cargo/reference/features.html
|
|
- This allows the use of `Into::into(e)` in `VerificationHandler` to
transform the error into an `anyhow::Error`.
|
|
- anyhow::Error isn't Clone, so we cannot, in general, duplicate the
error without losing information. We can try to downcast to the
most likely errors, and clone them, but this can never cover all
possibilities.
- Further, the error wrapped in std::io::Error isn't clone, so we
necessarily lose information when cloning this, even after we
changed Sequoia to return concrete errors.
- I think this is the best we can do, at least for now.
- Fixes #1068.
|
|
- See #1068.
|
|
- Denying all warnings means turning deprecation warnings into hard
errors, which turns semver-compatible updates of our dependencies
into compilation breaking updates if some functionality we use is
deprecated. This defeats the sole purpose of deprecating APIs.
- See https://gitlab.com/sequoia-pgp/sequoia/-/issues/827
|
|
- The proposal that once thought would end up as the next revision
of OpenPGP does not have the backing of the IETF OpenPGP working
group. We should not support it for the following reasons:
- Accepting it risks proliferation of a proprietary format.
- It is less scrutinized, and interactions with other versions
or features of the OpenPGP standard is not well understood.
Notably, as the "v5" Signature packets use an 8 octet length
counter in the footer, the hashed data streams alias with v3
Signatures. See also
https://gitlab.com/openpgp-wg/rfc4880bis/-/merge_requests/220
- Rejecting "v5" Signature Packets addresses these risks.
|
|
- The proposal that once thought would end up as the next revision
of OpenPGP does not have the backing of the IETF OpenPGP working
group. We should not support it for the following reasons:
- Accepting it risks proliferation of a proprietary format.
- It is less scrutinized, and interactions with other versions
or features of the OpenPGP standard is not well understood.
Notably, as the "v5" AEAD encrypted data packet doesn't use key
space separation, it cannot protect against cross-algorithm
attacks, so now the question of which algorithms are safe to use
depends on which packet they are used with.
- Rejecting "v5" AEAD Encrypted Data Packets addresses these risks.
|
|
|
|
|
|
|
|
|
|
- Notably, check the http status code.
|
|
|
|
|
|
- Fixes https://gitlab.com/sequoia-pgp/sequoia-sq/-/issues/88
|
|
- We may not understand all of the certs, but that is no reason not
to return them.
|
|
|
|
- Change both functions to return a vector of Result<Cert>. First,
the keyserver may return more than one cert for both user ID
searches as well as searches by key handle. Second, we may
understand not all certs returned by the server, and that is okay,
and we shouldn't let the whole query fail because of that.
- Previously, the functions made an attempt at validating the
results. However, that is flawed. First, in the case of
retrieval by key handle, the test was brittle and easily
circumvented by a key server. Second, the server may have good
reason to return an additional cert, even if it doesn't have the
key handle that the user asked for. For example, it may know that
a cert is superseded and return the new one too, as a courtesy.
draft-shaw-openpgp-hkp-00 doesn't forbid that.
- In the case of search by email address, the server may know the
association between the queried email address and the cert, even
if said association is not recorded in the cert itself.
- Remove the brittle checks, return all certs returned by the
server, add a warning to the documentation of KeyServer::get.
|
|
|
|
- We may not understand all of the returned certs, and that is
okay. Change the return type to reflect that.
- Also, one resource record may only contain one cert. Adapt
accordingly.
|
|
- This is likely an oversight in the original commit, as it wasn't
mentioned in the commit message. We don't have such an interface
for wkd or hkp either.
|
|
- As we use types from reqwest in our API, re-export it as a
courtesy for downstream consumers. This way, they can use the
re-exported reqwest and be confident that they use the correct
version.
|
|
- Fixes #840.
|
|
- This was duplicated by accident in
bc1f27770002690f6117eaec59e8b11ca6196489.
|
|
- Fixes #878.
|
|
- This is safe, as it is not possible to change the shape of the
data through a mutable reference (e.g. it is not possible to take
the secret key material away).
|
|
- Fixes #980.
|
|
in version 1.17.0 of sequoia-openpgp
|
|
- Fixes #1062.
|
|
|
|
- Tests that an inline-signed message using two different hash
algorithms verifies correctly.
|
|
|
|
- This triggers a warning in rustc 1.73, and thus is an error for
us.
|
|
|
|
- Fixes #1063.
|
|
|
|
|
|
|
|
|
|
- Upgrade clap from clap 3 to clap 4.
- Use the opportunity to change to clap's derive-style API.
|
|
|
|
|
|
- We've configured the gitlab project so that the only way to push
to main is via a merge request for which CI has passed. As such,
running (most) jobs when merging to main is a waste of resources,
and we don't do it by default.
- Fixes: #1061
|