Hi everyone,
I'm pleased to announce the release of version 0.8.0 of the Sequoia
Web of Trust crate, sequoia-wot.
I have published sequoia-wot on crates.io:
https://crates.io/crates/sequoia-wot
You can also fetch version 0.8.0 using the v0.8.0 tag:
https://gitlab.com/sequoia-pgp/sequoia-wot/-/tags/v0.8.0
which I signed:
$ git verify-tag v0.8.0
gpg: Signature made Tue Apr 18 14:12:35 2023 +02:00
gpg: using RSA key C03FA6411B03AE12576461187223B56678E02528
gpg: Good signature from "Neal H. Walfield <neal(a)walfield.org>" [ultimate]
gpg: "Neal H. Walfield <neal(a)gnupg.org>"
gpg: "Neal H. Walfield <neal(a)pep-project.org>"
gpg: "Neal H. Walfield <neal(a)pep.foundation>"
gpg: "Neal H. Walfield <neal(a)sequoia-pgp.org>"
This release updates a number of dependencies including updating the
sequoia-cert-store dependency to version 0.3.0, which is needed,
because users of sequoia-wot have to use the same version of
sequoia-cert-store as sequoia-wot.
Neal on behalf of the whole Sequoia PGP team
Hi everyone,
I'm pleased to announce the release of version 0.3.0 of the Sequoia
Certificate Store crate, sequoia-cert-store.
I have published sequoia-cert-store on crates.io:
https://crates.io/crates/sequoia-cert-store
You can also fetch version 0.3.0 using the v0.3.0 tag:
https://gitlab.com/sequoia-pgp/sequoia-cert-store/-/tags/v0.3.0
which I signed:
$ git verify-tag v0.3.0
gpg: Signature made Tue Apr 18 11:37:13 2023 +02:00
gpg: using RSA key C03FA6411B03AE12576461187223B56678E02528
gpg: Good signature from "Neal H. Walfield <neal(a)walfield.org>" [ultimate]
gpg: "Neal H. Walfield <neal(a)gnupg.org>"
gpg: "Neal H. Walfield <neal(a)pep-project.org>"
gpg: "Neal H. Walfield <neal(a)pep.foundation>"
gpg: "Neal H. Walfield <neal(a)sequoia-pgp.org>"
sequoia-cert-store provides a unified, high-level API for different
certificate stores via its `Store` and `StoreUpdate` traits.
This version includes a new backend, `Pep`. This backend supports the
certificate store format used by the pEp Engine:
https://gitea.pep.foundation/pEp.foundation/pEpEngine
And, we added functionality to directly add OpenPGP keyring files to a
`CertStore` using `CertStore::add_keyring` and
`CertStore::add_keyrings`.
We also fixed a few minor bugs.
Neal on behalf of the whole Sequoia PGP team
Hi everyone,
I'm pleased to announce v1.4.0 of the RPM Sequoia crate.
I have published rpm-sequoia on crates.io:
https://crates.io/crates/rpm-sequoia
You can also fetch version 1.4.0 using the v1.4.0 tag:
https://github.com/rpm-software-management/rpm-sequoia/releases/tag/v1.4.0
which I signed:
$ git verify-tag v1.4.0
gpg: Signature made Thu Apr 13 23:10:27 2023 +02:00
gpg: using RSA key C03FA6411B03AE12576461187223B56678E02528
gpg: Good signature from "Neal H. Walfield <neal(a)walfield.org>" [ultimate]
gpg: "Neal H. Walfield <neal(a)gnupg.org>"
gpg: "Neal H. Walfield <neal(a)pep-project.org>"
gpg: "Neal H. Walfield <neal(a)pep.foundation>"
gpg: "Neal H. Walfield <neal(a)sequoia-pgp.org>"
The most notable change in this release is better error reporting.
Based on feedback from users of rpm on Fedora 38 beta, we learned that
many certificates, and many packages use outdated cryptography, or are
generated from broken OpenPGP implementations. As sequoia-openpgp is
more strict in what it accepts than rpm's deprecated internal OpenPGP
implementation, installing these packages now results in an error.
Although rpm-sequoia often knows in detail why a certificate or
signature is invalid, rpm did not have a way to return this
information. As such, rpm could only print out that the package could
not be installed, like this:
```
$ rpm -i google-chrome-stable-109.0.5414.119-1.x86_64.rpm
warning: google-chrome-stable-109.0.5414.119-1.x86_64.rpm: Header V4 DSA/SHA1 Signature, key ID 7fac5991: NOTTRUSTED
package google-chrome-stable-109.0.5414.119-1.x86_64 does not verify: Header V4 DSA/SHA1 Signature, key ID 7fac5991: NOTTRUSTED
```
This release introduces two new functions, which are identical to
existing functions in their functionality, but also return rich error
messages, which will hopefully help users more easily diagnose the
underlying problem. For instance, using a patched version of rpm,
which uses these new interfaces, here's what happens when trying to
install a package whose signature can't be verified:
```
$ rpm -i google-chrome-stable-109.0.5414.119-1.x86_64.rpm
error: Verifying a signature using certificate 4CCA1EAF950CEE4AB83976DCA040830F7FAC5991 (Google, Inc. Linux Package Signing Key <linux-packages-keymaster(a)google.com>):
1. Signature 02b3 created at Mon Jan 23 21:23:32 2023 invalid: signature relies on legacy cryptography
because: Policy rejected non-revocation signature (Binary) requiring collision resistance
because: SHA1 is not considered secure since 1970-01-01T00:00:00Z
2. Certificate A040830F7FAC5991 invalid: policy violation
because: No binding signature at time 2023-01-23T21:23:32Z
because: Policy rejected non-revocation signature (PositiveCertification) requiring second pre-image resistance
because: SHA1 is not considered secure since 1970-01-01T00:00:00Z
warning: google-chrome-stable-109.0.5414.119-1.x86_64.rpm: Header V4 DSA/SHA1 Signature, key ID 7fac5991: NOTTRUSTED
error: Failed dependencies:
rpmlib(PayloadIsXz) <= 5.2-1 is needed by google-chrome-stable-109.0.5414.119-1.x86_64
$ rpm -i anydesk-6.1.1-1.el7.x86_64.rpm
error: Verifying a signature using certificate D56311E5FF3B6F39D5A16ABE18DF3741CDFFDE29 (philandro Software GmbH <info(a)philandro.com>):
1. Signature 9b8f created at Tue Apr 13 11:08:37 2021 invalid: signature relies on legacy cryptography
because: Policy rejected non-revocation signature (Binary) requiring collision resistance
because: SHA1 is not considered secure since 1970-01-01T00:00:00Z
2. Certificate 18DF3741CDFFDE29 invalid: policy violation
because: No binding signature at time 2021-04-13T11:08:37Z
error: anydesk-6.1.1-1.el7.x86_64.rpm: Header V3 RSA/SHA1 Signature, key ID cdffde29: BAD
error: anydesk-6.1.1-1.el7.x86_64.rpm cannot be installed
```
And here's what rpm emits when trying to install a package with an
incorrectly generated signature:
```
$ rpm -i intel-oneapi-common-licensing-2023.1.0-2023.1.0-43473.noarch.rpm
error: intel-oneapi-common-licensing-2023.1.0-2023.1.0-43473.noarch.rpm: Header RSA signature: BAD (package tag 268: invalid OpenPGP signature: Parsing an OpenPGP packet:
Failed to parse Signature Packet
because: Signature appears to be created by a non-conformant OpenPGP implementation, see <https://github.com/rpm-software-management/rpm/issues/2351>.
because: Malformed MPI: leading bit is not set: expected bit 8 to be set in 101 (5))
error: intel-oneapi-common-licensing-2023.1.0-2023.1.0-43473.noarch.rpm cannot be installed
```
Neal on behalf of the whole Sequoia PGP team
Hi everyone,
I'm pleased to announce the release of version 0.29.0 of Sequoia sq,
our general-purpose command-line tool for Sequoia PGP.
I have published sequoia-sq on crates.io:
https://crates.io/crates/sequoia-sq
You can also fetch version 0.29.0 using the v0.29.0 tag:
https://gitlab.com/sequoia-pgp/sequoia-sq/-/tags/v0.29.0
which I signed:
$ git verify-tag v0.29.0
gpg: Signature made Fri Apr 07 23:52:44 2023 +02:00
gpg: using RSA key C03FA6411B03AE12576461187223B56678E02528
gpg: Good signature from "Neal H. Walfield <neal(a)walfield.org>" [ultimate]
gpg: "Neal H. Walfield <neal(a)gnupg.org>"
gpg: "Neal H. Walfield <neal(a)pep-project.org>"
gpg: "Neal H. Walfield <neal(a)pep.foundation>"
gpg: "Neal H. Walfield <neal(a)sequoia-pgp.org>"
sq version 0.29.0 is packed full of exciting, user-visible changes.
This release of sq is the culmination of two years of work, and
includes several major user-visible improvements. To date, sq has
operated in a stateless manner: users explicitly passed the keys and
certificates that it should operate on, and implemented their own
trust model by maintaining an ad-hoc curated keyring. Version 0.29.0
of sq adds support for a certificate store, includes a powerful
web-of-trust engine based on flow networks, and introduces an
easier-to-use interface, sq link, to manage authentication decisions
based on concepts from how people use address books.
Here's a quick demo of downloading a certificate from
keys.openpgp.org:
$ sq keyserver get neal(a)sequoia-pgp.org
Recorded provenance information for DC09F5862D531848CBC4C0D8C6AD186AB030E354,
"Downloaded from the keyserver keys.openpgp.org"
Created the local CA "Downloaded from the keyserver keys.openpgp.org" for
certifying certificates downloaded from this service. The CA's trust amount
is set to 1 of 120.
Use `sq link add --ca '*' --amount N DC09F5862D531848CBC4C0D8C6AD186AB030E354`
to override it. Or `sq link retract DC09F5862D531848CBC4C0D8C6AD186AB030E354`
to disable it.
Recorded provenance information for 8F17777118A33DDA9BA48E62AACB3243630052D9, "Neal H. Walfield <neal(a)gnupg.org>"
Recorded provenance information for 8F17777118A33DDA9BA48E62AACB3243630052D9, "Neal H. Walfield <neal(a)pep-project.org>"
Recorded provenance information for 8F17777118A33DDA9BA48E62AACB3243630052D9, "Neal H. Walfield <neal(a)sequoia-pgp.org>"
Recorded provenance information for 8F17777118A33DDA9BA48E62AACB3243630052D9, "Neal H. Walfield <neal(a)walfield.org>"
Importing 1 certificates into the certificate store:
1. 8F17777118A33DDA9BA48E62AACB3243630052D9 Neal H. Walfield <neal(a)walfield.org>
Imported 1 new certificates, updated 0 certificates, 0 certificates unchanged, 0 errors.
After checking that a certificate really belongs to the stated owner, use
"sq link add FINGERPRINT" to mark the certificate as authenticated.
We see that `sq` has saved the provenance information, and explains
how to link the certificate and the identity. When we now look up the
certificate associated with neal(a)sequoia-pgp.org, we see that it has
been certified by a minimally trusted, local, shadow CA for
keys.openpgp.org, which is in turn certified by the local trust root:
$ sq wot lookup --email neal(a)sequoia-pgp.org
[ ] 8F17777118A33DDA9BA48E62AACB3243630052D9 Neal H. Walfield <neal(a)sequoia-pgp.org>: marginally authenticated (0%)
◯ 15BEF9EDD4759647BE5F008AAD0B4189CE8A7D1B ("Local Trust Root")
│ partially certified (amount: 1 of 120) the following certificate on 2023-04-07 as a partially trusted (1 of 120) introducer (depth: 1)
├ DC4981E703D4448C778396EDA349F3FA419E04AC ("Downloaded from the keyserver keys.openpgp.org")
│ certified the following binding on 2023-04-07
└ 8F17777118A33DDA9BA48E62AACB3243630052D9 "Neal H. Walfield <neal(a)sequoia-pgp.org>"
Could not authenticate any paths.
If we are convinced that keys.openpgp.org is reliable, then we can
easily change how much we rely on the the shadow CA to check email
addresses:
$ sq link add --ca \* DC4981E703D4448C778396EDA349F3FA419E04AC --all
DC4981E703D4448C778396EDA349F3FA419E04AC, Downloaded from the keyserver
keys.openpgp.org was already linked at 2023-04-07 22:34:48 UTC.
Updating trust amount: 1 -> 120.
Update trust depth: 1 -> 255.
Updating exportable flag: true -> false.
Link parameters changed, updating link.
Linking DC4981E703D4448C778396EDA349F3FA419E04AC and
"Downloaded from the keyserver keys.openpgp.org".
Now, that certificate and any user IDs that were returned by
keys.openpgp.org are considered fully authenticated:
$ sq wot lookup --email neal(a)sequoia-pgp.org
[✓] 8F17777118A33DDA9BA48E62AACB3243630052D9 Neal H. Walfield <neal(a)sequoia-pgp.org>: fully authenticated (100%)
◯ 15BEF9EDD4759647BE5F008AAD0B4189CE8A7D1B ("Local Trust Root")
│ certified the following certificate on 2023-04-07 as a fully trusted meta-introducer (depth: unconstrained)
├ DC4981E703D4448C778396EDA349F3FA419E04AC ("Downloaded from the keyserver keys.openpgp.org")
│ certified the following binding on 2023-04-07
└ 8F17777118A33DDA9BA48E62AACB3243630052D9 "Neal H. Walfield <neal(a)sequoia-pgp.org>"
And we can address the certificate by user ID or email:
$ echo 'Hi Neal!' | sq encrypt --recipient-email neal(a)walfield.org
-----BEGIN PGP MESSAGE-----
...
If we ever change our mind about how much we are willing to rely on
keys.openpgp.org, we can easily modify the link, or even retract it:
$ sq link retract DC4981E703D4448C778396EDA349F3FA419E04AC
DC4981E703D4448C778396EDA349F3FA419E04AC, Downloaded from the keyserver
keys.openpgp.org was linked at 2023-04-07 22:37:52 UTC.
Updating trust amount: 120 -> 0.
Update trust depth: 255 -> 0.
Link parameters changed, updating link.
Breaking link between DC4981E703D4448C778396EDA349F3FA419E04AC and
"Downloaded from the keyserver keys.openpgp.org".
$ sq link list
DC4981E703D4448C778396EDA349F3FA419E04AC, "Downloaded from the keyserver
keys.openpgp.org"'s link was retracted.
I've published an introduction to all the new functionality as well as
the motivation for some of our unconventional design decisions in a
blog post:
https://sequoia-pgp.org/blog/2023/04/08/sequoia-sq/
The list of changes in 0.29 is:
* New functionality
- `sq` now supports and implicitly uses a certificate store. By
default, `sq` uses the standard OpenPGP certificate directory.
This is located at `$HOME/.local/share/pgp.cert.d` on XDG
compliant systems.
- `sq --no-cert-store`: A new switch to disable the use of the
certificate store.
- `sq --cert-store`: A new option to use an alternate certificate
store. Currently, only OpenPGP certificate directories are
supported.
- `sq import`: A new command to import certificates into the
certificate store.
- `sq export`: A new command to export certificates from the
certificate store.
- `sq encrypt --recipient-cert`: A new option to specify a
recipient's certificate by fingerprint or key ID, which is then
looked up in the certificate store.
- `sq verify --signer-cert`: A new option to specify a signer's
certificate by fingerprint or key ID, which is then looked up in
the certificate store.
- `sq verify` now also implicitly looks for missing certificates in
the certificate store. But, unless they are explicitly named
using `--signer-cert`, they are not considered authenticated and
the verification will always fail.
- `sq certify`: If the certificate to certify is a fingerprint or
Key ID, then the corresponding certificate is looked up in the
certificate store.
- Add a global option, `--time`, to set the reference time. This
option replaces the various subcommand's `--time` argument as
well as `sq key generate` and `sq key userid add`'s
`--creation-time` arguments.
- Add top-level option, `--trust-root`, to allow the user to
specify trust roots.
- Extend `sq encrypt` to allow addressing recipients by User ID
(`--recipient-userid`) or email address (`--recipient-email`).
Only User IDs that can be fully authenticated are considered.
- Extend `sq verify` to verify certificates looked up from the
certificate store using the web of trust. If the signature
includes a Signer's User ID packet, and the binding can be fully
authenticated, consider the signature to be authenticated. If
there is no Signer's User ID packet, consider the signature to be
authenticated if any binding can fully be authenticated.
- Add `sq link add`, which uses the local trust root to
certify the specified bindings.
- Add `sq link retract`, which retracts certifications made by the
local trust root on the specified bindings.
- Add `sq link list`, which lists the links.
- Add a top-level option, `--keyring`, to allow the user to specify
additional keyrings to search for certificates.
- Import web of trust subcommands from sq-wot. Specifically, add:
- `sq wot authenticate` to authenticate a binding.
- `sq wot lookup` to find a certificate with a particular User ID.
- `sq wot identify` to list authenticated bindings for a
certificate.
- `sq wot list` to list authenticated bindings.
- `sq wot path` to authenticate and lint a path in a web of trust.
- `sq keyserver get`, `sq wkd get`, and `sq dane get` now import any
certificates into the certificate store by default instead of
exporting them on stdout. It is still possible to export them
using the `--output` option.
- When `sq keyserver get` (for verifying key servers), `sq wkd get`,
or `sq dane get` saves a certificate to the local certificate
store, `sq` certifies the validated User IDs (all returned User
IDs in the case of verifying key servers; User IDs that contain
the looked up email address in the case of WKD and DANE) using a
local service-specific proxy CA. If the proxy key doesn't exist,
it is created, and certified as a minimally trusted CA (trust
amount 1 of 120) by the local trust root. The proxy certificates
can be managed in the usual way using `sq link add` and `sq link
retract`.
- Extend `sq inspect` to inspect certificates from the certificate
store using the `--cert` option.
* Deprecated functionality
- `sq key generate --creation-time TIME` is deprecated in favor of
`sq key generate --time TIME`.
- `sq key user id --creation-time TIME` is deprecated in favor of
`sq user id --time TIME`.
Neal on behalf of the whole Sequoia PGP team
Hi everyone,
I'm pleased to announce the release of version 0.7.1 of the Sequoia
Web of Trust crate, sequoia-wot.
I have published sequoia-wot on crates.io:
https://crates.io/crates/sequoia-wot
You can also fetch version 0.7.1 using the v0.7.1 tag:
https://gitlab.com/sequoia-pgp/sequoia-wot/-/tags/v0.7.1
which I signed:
$ git verify-tag v0.7.1
gpg: Signature made Fri Apr 07 21:31:36 2023 +02:00
gpg: using RSA key C03FA6411B03AE12576461187223B56678E02528
gpg: Good signature from "Neal H. Walfield <neal(a)walfield.org>" [ultimate]
gpg: "Neal H. Walfield <neal(a)gnupg.org>"
gpg: "Neal H. Walfield <neal(a)pep-project.org>"
gpg: "Neal H. Walfield <neal(a)pep.foundation>"
gpg: "Neal H. Walfield <neal(a)sequoia-pgp.org>"
This release fixes a minor bug. Unfortunately, certifications of User
IDs that are not self-signed were ignored. This feature is useful for
implementing petnames. This is now fixed.
https://en.wikipedia.org/wiki/Petname
Neal on behalf of the whole Sequoia PGP team