| Age | Commit message (Collapse) | Author |
|---|
|
- Add `CertBuilder::set_exportable`, which sets the exportable flag
accordingly on all generated signatures.
- This allows the easy creation of non-exportable certificates,
which is recommended by the OpenPGP Certificate Directory
specification for the local trust root:
> The trust root is an OpenPGP certificate that is stored under
> the special name trust-root.
>
> The certificate:
>
> SHOULD use direct key signatures or binding signatures that are marked as non-exportable.
https://www.ietf.org/archive/id/draft-nwjw-openpgp-cert-d-00.html#section-3.5.1
- Fixes #1082.
|
|
- Ed25519 keys use the EdDSA signature algorithm, but the
documentation mentions parameters for ECDH.
- It appears that the documentation was copied from
`Key4::import_public_cv25519`, and not adjusted.
- Fix it.
|
|
- Ed25519 keys use the EdDSA signature algorithm, but the
documentation mentions parameters for ECDH.
- It appears that the documentation was copied from
`Key4::import_secret_cv25519`, and not adjusted.
- Fix it.
|
|
- Add a buffered-reader-based function to trait Parse. This allows
us to manipulate the buffered reader stack before and after
parsing, e.g. to parse several armored objects in one stream. The
CertParser also does this, but uses internal interfaces for that.
|
|
- This is an internal interface that uses our reader stack's
cookie. We need this to traverse the buffered reader stack. We
did not, however, expose it as an external interface, because we
didn't want to bake in the cookie type into the API.
- Having a public API that operates on buffered readers is
convenient: the current Parser::from_reader operates on
io::Readers, and will most likely construct a
buffered_reader::Generic from it. This will eagerly buffer some
data, making this interface unsuitable if you want to read in one
artifact (e.g. an MPI) without consuming more data.
- Renaming the internal functions gives us a chance to add a more
general buffered reader interface.
|
|
|
|
- Previously, we emitted the PRIVATE KEY label when armoring TSKs
that don't in fact contain secrets, confusing users.
- See https://gitlab.com/sequoia-pgp/sequoia-sq/-/issues/14
- Fixes #1075.
|
|
|
|
- The public ABI has a bug.
- The documentation for `Key` says that a `Key<SecretParts, R>`
must have secret key material:
> If P is key::SecretParts, then the key definitely contains
> secret key material (although it is not guaranteed that the secret
> key material is valid), and methods that require secret key
> material are available.
https://gitlab.com/sequoia-pgp/sequoia/-/blob/a9982139/openpgp/src/packet/mod.rs#L1249-1256
- Unfortunately, we accidentally provided infallible conversions from
`Key<PublicParts, R1>` to `Key<SecretsParts, R2>` and
`Key<UnspecifiedParts, R1>` to `Key<SecretsParts, R2>` where
`R1 != R2`.
- These conversions are wrong, and useless: attempting to use a
method on a `Key<SecretsParts, R2>` that expects the `Key` to have
secret key material, but doesn't results in a panic.
- Removing these methods converts run-time errors into compile-time
errors. As such, we do not consider this change to result in a
change to the semantic version.
- Make the conversions to `Key<key::SecretsParts, R>` fallible.
- Fixes #740.
|
|
|
|
- We've split `sq` and `sqv` into their own repositories. Update
the links.
- #999.
|
|
- 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.
|
