Re: Sequoia PGP : What are the options for expired third party GPG signing keys?
Antoine Zellmeyer via devel writes: > Sorry for the late answer, It seems to be working :) I was able to import and > install packages signed with this certificate. Thanks for confirming that it works as expected. I've made a new release of rpm-sequoia, which includes this fix. I expect that decathorpe will package it in the coming days. :) Neal -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Sequoia PGP : What are the options for expired third party GPG signing keys?
Hi Antoine Antoine Zellmeyer via devel writes: > Thanks ! I'll follow this issue. Great. I posted a fix. It would be helpful if you could test that it works for your case. Specifically, it would be helpful to hear back that it: - imports the certificate, and - you are able to install packages signed by the expired certificate. Note: you only need to rebuild rpm-sequoia; you don't have to rebuild rpm. When running rpm and rpmkeys, use LD_PRELOAD to override the library. :) Neal -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Sequoia PGP : What are the options for expired third party GPG signing keys?
Hi Antoine, Antoine Zellmeyer via devel writes: > Following Fedora’s migration to Sequoia PGP, it seems that it isn’t possible > to import an expired signing key anymore. > > rpm --import https://some.domain/public-keys/SOME_EXPIRED_RPM_KEY.public > error: Certificate : > The certificate is expired: The primary key is not live > error: https://some.domain/public-keys/SOME_EXPIRED_RPM_KEY.public: key 1 > import failed. > > I’d like to know what a third party can do to allow older versions of a > package to be installed despite the expired GPG key. To be precise, the GPG > key is expired but not revoked so it shouldn’t be an issue. > One option I’m aware of would be to resign older packages but it involves > changing the checksum of the package, which is a bad practice we’d like to > avoid. Any suggestions ? Or is it an issue to redirect to rpm-sequoia > directly ? Thanks for identifying this issue and reporting it. In general, a certificate that has expired or been soft revoked (i.e., not compromised [1]) should still be able to verify signatures made before the certificate expired or was soft revoked. I've opened an issue in rpm-sequoia [2]. :) Neal [1] https://datatracker.ietf.org/doc/html/rfc4880#section-5.2.3.23 [2] https://github.com/rpm-software-management/rpm-sequoia/issues/59 -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Fedora Copr builders updated to Fedora 38
Hi Pavel,
On Wed, 14 Jun 2023 11:27:35 +0200,
Pavel Raiskup wrote:
> On úterý 13. června 2023 16:57:42 CEST Neal H. Walfield wrote:
> > On Thu, 08 Jun 2023 21:37:09 +0200,
> > Ondřej Budai wrote:
> > > RPM Sequoia's crypto policies can be configured, so you should be able to
> > > re-enable SHA-1. However, this would
> > > be a global change, not only for EL6... See
> > > https://docs.rs/sequoia-policy-config/latest/sequoia_policy_config/#hash-functions
> > > ...
> > > On Thu, Jun 8, 2023 at 5:42 PM Pavel Raiskup wrote:
> > >
> > > Hello maintainers!
> > >
> > > Copr builders have been updated to Fedora 38 today (some old builders
> > > might still be running F37 ATM, but when they finish the task(s) they
> > > work on, they will be deleted). Our testsuite is passing just fine, so
> > > you _should_ be fine too :-). Please let us know if you have some
> > > troubles.
> > >
> > > There was one important change in Fedora 38 - RPM switched to the
> > > Sequoia crypto backend. It refuses SHA-1 in crypto; which basically
> > > disallows Mock to properly check EL6 GPG signatures. To allow further
> > > builds, we switched to gpgcheck=0 for all epel-6 chroots. If you know a
> > > better work-around, let me know.
> >
> > I find this behavior surprising. The default policy as set by
> > fedora-crypto-policies is for rpm-sequoia is to accept SHA-1 (and
> > DSA-1024, ...):
> >
> >
> > https://gitlab.com/redhat-crypto/fedora-crypto-policies/-/blob/master/policies/FEDORA38.pol#L75
> >
> > What policy are you using?
>
> I was wrong. The problem was *not* with the EPEL-6 signatures, but with
> CentOS 6 signatures. It is a bit harder to analyse, as
> `sq-keyring-linter` is silent for that one:
>
> $ sq-keyring-linter <
> /usr/share/distribution-gpg-keys/centos/RPM-GPG-KEY-CentOS-6
> $ echo $?
> 0
Thanks for investigating, I opened an issue on our issue tracker about
it here:
https://gitlab.com/sequoia-pgp/keyring-linter/-/issues/20
Using https://www.centos.org/keys/RPM-GPG-KEY-CentOS-6, it appears
that the CentOS 6 key expired in July 2021. The linter checks if a
certificate is invalid under the standard policy, but valid under the
standard policy + SHA-1. Since the certificate is expired, it's
considered invalid in both cases, and it concludes that the
certificate doesn't have any issues. Using faketime to examine the
certificate when it wasn't expired, we see:
$ faketime 2021-01-01 sq-keyring-linter RPM-GPG-KEY-CentOS-6
Certificate 0946FCA2C105B9DE is not valid under the standard policy: No
binding signature at time 2020-12-31T23:00:00Z
Certificate 0946FCA2C105B9DE contains a User ID ("CentOS-6 Key (CentOS 6
Official Signing Key) ") protected by SHA-1
Examined 1 certificate.
0 certificates are invalid and were not linted. (GOOD)
1 certificate was linted.
1 of the 1 certificates (100%) has at least one issue. (BAD)
0 of the linted certificates were revoked.
0 of the 0 certificates has revocation certificates that are weaker than
the certificate and should be recreated. (GOOD)
0 of the linted certificates were expired.
1 of the non-revoked linted certificate has at least one non-revoked User ID:
1 has at least one User ID protected by SHA-1. (BAD)
1 has all User IDs protected by SHA-1. (BAD)
0 of the non-revoked linted certificates have at least one non-revoked, live
subkey:
0 have at least one non-revoked, live subkey with a binding signature that
uses SHA-1. (GOOD)
0 of the non-revoked linted certificates have at least one non-revoked, live,
signing-capable subkey:
0 certificates have at least one non-revoked, live, signing-capable subkey
with a strong binding signature, but a backsig that uses SHA-1. (GOOD)
Neal
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it:
https://pagure.io/fedora-infrastructure/new_issue
Re: Fedora Copr builders updated to Fedora 38
On Thu, 08 Jun 2023 21:37:09 +0200, Ondřej Budai wrote: > RPM Sequoia's crypto policies can be configured, so you should be able to > re-enable SHA-1. However, this would > be a global change, not only for EL6... See > https://docs.rs/sequoia-policy-config/latest/sequoia_policy_config/#hash-functions > ... > On Thu, Jun 8, 2023 at 5:42 PM Pavel Raiskup wrote: > > Hello maintainers! > > Copr builders have been updated to Fedora 38 today (some old builders > might still be running F37 ATM, but when they finish the task(s) they > work on, they will be deleted). Our testsuite is passing just fine, so > you _should_ be fine too :-). Please let us know if you have some > troubles. > > There was one important change in Fedora 38 - RPM switched to the > Sequoia crypto backend. It refuses SHA-1 in crypto; which basically > disallows Mock to properly check EL6 GPG signatures. To allow further > builds, we switched to gpgcheck=0 for all epel-6 chroots. If you know a > better work-around, let me know. I find this behavior surprising. The default policy as set by fedora-crypto-policies is for rpm-sequoia is to accept SHA-1 (and DSA-1024, ...): https://gitlab.com/redhat-crypto/fedora-crypto-policies/-/blob/master/policies/FEDORA38.pol#L75 What policy are you using? Neal ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: LibreOffice packages
On Tue, 06 Jun 2023 18:07:04 +0200, Fabio Valentini wrote: > On the other hand, the libreoffice flatpak bundles ~80 projects: > - gpgme (huh?) This... > - openldap (huh?) and perhaps this are probably because it is possible to sign and encrypt ODF documents using OpenPGP. Some details are here: https://help.libreoffice.org/latest/en-US/text/shared/guide/openpgp.html Neal ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: RPM Sequoia: A Sequoia-based backend for the RPM Package Manager
Hi Bob,
On Thu, 27 Apr 2023 19:55:42 +0200,
Robert Relyea wrote:
> A good read indeed.
Thanks, I'm happy you enjoyed it :).
> I do wonder about the error message:
>
> because: SHA1 is not considered secure since 1970-01-01T00:00:00Z
>
> I'm not sure where the date came from, but SHA1 wasn't published until 1993.
> 1970-01-01 looks like an epic of
> some kind. If you must include a 'not considered secure' date it should be
> something between 2010 and 2017
> (2010 when peole started worrying about sha1, 2011 and 2013 when NIST said
> 'stop using it' and 2017 when
> Google (ironically - since they are the ones still signing packages with it)
> actually broke it). Probably best to
> drop the not considered secure if the received date is null.
Good catch!
In Sequoia, we have high-level policy objects that are passed to every
method that directly or indirectly does a cryptographic operation.
Before doing something that relies on cryptography, a method checks
that the operation is allowed by the policy. If the policy returns an
error, the caller adds some additional context to the error message,
and then returns the error. For instance, before using a signature in
a context that requires second pre-image resistance, a method might
do:
```rust
policy.signature(, HashAlgoSecurity::SecondPreImageResistance)
.context("Checking ...")?;
```
Our `StandardPolicy` associates a cutoff time with each algorithm. By
default, SHA-1 is considered acceptable in a context that requires
collision resistance until 2013, and acceptable in a context that
requires second pre-image resistance until 2023:
https://docs.sequoia-pgp.org/src/sequoia_openpgp/policy.rs.html#628
https://docs.sequoia-pgp.org/src/sequoia_openpgp/policy.rs.html#646
We had two use cases in mind when we designed the cutoff system.
First, using cutoffs, it is possible to sunset an algorithm. For
instance, we released version 1.0 of sequoia-openpgp in 2020. At that
time, the world already knew that SHA-1 was broken. To allow a
transition period, we decided to set the cutoff for SHA-1 to 2023.
(We already worked on tooling to help with the transition, like
`sq-keyring-linter`, https://gitlab.com/sequoia-pgp/keyring-linter .)
In this way, no software update was required to disable SHA-1; all
Sequoia users disabled SHA-1 at the same time.
Second, OpenPGP is often used to work with archived data. When
verifying a signature, we should apply the policy from the time the
signed data was initially received. (If we don't know when the data
was received, then we conservatively assume the current time.) This
means if I have a signature that relies on SHA-1, and I store the data
on a trusted medium, then I can use the time that it was stored as the
reference time, like so:
```shell
$ sq verify --time 20080428 /tmp/msg.asc
```
When we spoke about this with the Fedora Crypto Policy team, they
decided to not use cutoffs, but a simpler binary allowed / not
allowed. Since OpenPGP time started on January 1, 1970, setting the
cutoff time to January 1, 1970 means that an algorithm is always
considered to be broken. And, that's how it is implemented, and why
the error message includes that time.
That said, yes we realize the error is confusing, and we plan to add a
special error message for this case:
https://gitlab.com/sequoia-pgp/sequoia/-/issues/1000
Thanks!
:) Neal
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it:
https://pagure.io/fedora-infrastructure/new_issue
RPM Sequoia: A Sequoia-based backend for the RPM Package Manager
Hi all, A year and a half ago, I began working with Panu on using Sequoia as RPM's OpenPGP parser. I wrote up our journey from the initial analysis, to adding the code to RPM, and to getting it into Fedora 38 (yay!) in a blog post. I'm mentioning it here, as I believe it is of general interest to this community. If this is considered off topic, I apologize in advance. https://sequoia-pgp.org/blog/2023/04/27/rpm-sequoia/ :) Neal ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: crypto-policies
Hi Zbyszek, Thanks for the clarifications. Neal On Mon, 27 Mar 2023 14:32:58 +0200, Zbigniew Jędrzejewski-Szmek wrote: > On Mon, Mar 27, 2023 at 01:29:38PM +0200, Neal H. Walfield wrote: > > On Mon, 27 Mar 2023 13:16:45 +0200, > > Zbigniew Jędrzejewski-Szmek wrote: > > > I agree. The scope of the issue is fairly narrow, and the underlying > > > issue is an invalid signature made by the anydesk maintainers. > > > We also have a simple command that users can use to work around > > > the issue. > > > > If you are thinking of sq-keyring-linter, that won't help here. This > > is not a SHA-1 issue. > > I know. I mentioned neither of those two things ;) > > The workaround I had in mind: add '--exclude-anydesk'. > We don't have a good replacement for graphical users yet, but I'm > sure we'll be able to write something up in CommonBugs before F38 is released. > > > The issue (I think) is that the anydesk maintains were too aggressive > > in what they striped when they exported the OpenPGP certificate. > [snip] > > Yes, probably. Anyway, the end result is that "based on the knowledge > that Sequoia has, the certificate was not valid when the signature was > made." (This is based on your comment [1]. I'm reproducing this > here for others.) > > [1] https://bugzilla.redhat.com/show_bug.cgi?id=2170878#c124 > > Zbyszek > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org > Do not reply to spam, report it: > https://pagure.io/fedora-infrastructure/new_issue ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: crypto-policies
On Mon, 27 Mar 2023 13:16:45 +0200, Zbigniew Jędrzejewski-Szmek wrote: > I agree. The scope of the issue is fairly narrow, and the underlying > issue is an invalid signature made by the anydesk maintainers. > We also have a simple command that users can use to work around > the issue. If you are thinking of sq-keyring-linter, that won't help here. This is not a SHA-1 issue. The issue (I think) is that the anydesk maintains were too aggressive in what they striped when they exported the OpenPGP certificate. They probably ran: `gpg --export --export-options export-minimal FINGERPRINT`. According to the gpg manual page, that does: ``` export-minimal Export the smallest key possible. This removes all signatures except the most recent self-signature on each user ID. This option is the same as running the '--edit-key' command "minimize" before export except that the local copy of the key is not modified. Defaults to no. ``` This makes sense when sharing an OpenPGP certificate via email, say, so that someone can (in the future) send you an encrypted message. But it doesn't make sense when sending the certificate to someone who should then verify past signatures, which is the case here. Neal ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
crypto-policies
Hi Ben, Thanks for working on this. On Fri, 24 Mar 2023 19:25:46 +0100, Ben Cotton wrote: > Accepted blockers > - > > 1. crypto-policies ― Insecure installed RPMs (like Google Chrome) > prevent system updates in F38, can't be removed ― ASSIGNED > ACTION: Maintainers to propose solution for this case ... > Bug-by-bug detail > = > > Accepted blockers > - > > 1. crypto-policies ― > https://bugzilla.redhat.com/show_bug.cgi?id=2170878 ― ASSIGNED > Insecure installed RPMs (like Google Chrome) prevent system updates in > F38, can't be removed > > A fix to let RPM use a separate crytpo policy has not covered all > cases. Certain AnyDesk RPMs were apparently signed outside the window > when the certificate was valid. Panu wrote https://bugzilla.redhat.com/show_bug.cgi?id=2170878#c126 : > To me the key points here are > 1) there's a lot of obsolete/broken crypto out there > 2) we need better error messages > > Properly dealing with 2) needs an API redesign, but we'll try to work out > some sort of bandaid solution. Are better diagnostics sufficient from your point of view, or are you looking for a different solution? Thanks in advance for providing some more clarity here. Neal ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: F38 proposal: RPM Sequoia (System-Wide Change proposal)
Hi Simo, On Fri, 14 Oct 2022 18:28:01 +0200, Simo Sorce wrote: > At this time, as far as I know, there is no OpenPGP work of any kind on > supporting PQC algorithms. Furthermore the way we use signatures in RPM > really has no resemblance to the scenarios OpenPGP was built for. > > So we should consider whether moving to PQC will also mean moving off > OpenPGP as our signature format and into something simpler. A draft for PQC in OpenPGP was published today: https://mailarchive.ietf.org/arch/msg/openpgp/zjbIqesTdiYfA7vkyMZ6EM9KWrA/ https://datatracker.ietf.org/doc/draft-wussler-openpgp-pqc/ Neal ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: F38 proposal: RPM Sequoia (System-Wide Change proposal)
Hi Simo, On Fri, 14 Oct 2022 22:36:09 +0200, Neal H. Walfield wrote: > On Fri, 14 Oct 2022 18:28:01 +0200, > Simo Sorce wrote: > > At this time, as far as I know, there is no OpenPGP work of any kind on > > supporting PQC algorithms. > > The German BSI contracted MTG AG to design and implement PQC for > OpenPGP. They presented their work at IETF 113, and at the OpenPGP > email summit this past May. > > https://datatracker.ietf.org/meeting/113/materials/agenda-113-openpgp-01 The OpenPGP session at IETF 115 (Tuesday Nov 8th, 1300-1430 UTC) will include a discussion on PQC in OpenPGP: https://datatracker.ietf.org/doc/agenda-115-openpgp/ That will be followed by a side meeting dedicated to PQC in OpenPGP: https://mailarchive.ietf.org/arch/msg/openpgp/ZTPCQQ13OookbjmSNeyptR4ItcM/ I hope you'll be able to attend and raise your concerns. Neal ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: RPM Sequoia - respect system's crypt policy
On Thu, 13 Oct 2022 09:29:27 +0200, Panu Matilainen wrote: > >> - Some old, insecure (MD5/SHA1 based) signatures are rejected (this is > >> in line with the stronger crypto settings proposed elsewhere for F38) > > > > Such a hardcoded restriction, without a way for the local administrator to > > allow the legacy signatures, is not acceptable. > > Mind you, I don't exactly agree with this style of explicit disabling > either (see > https://lists.rpm.org/pipermail/rpm-maint/2021-October/018344.html and > onwards). But. I doubt many people realize just how thin the ice is > (and has always been) with the existing parser. I consider this step a > matter of survival, and ultimately some legacy content becoming harder > to use is an acceptable tradeoff for *that*. > > I don't know how deep this all is wired inside Sequoia, but I totally > agree (as you see in the thread linked above) that this should be > based on the system crypto policy. As explained in the change, nettle > (which doesn't support the system crypto policies AIUI) should be seen > as a temporary stepstone in Fedora, with a plan to switch to openssl > (which does) in the nearish future. > > So technically this is a matter of "Sequoia should honor system crypto > policy", rpm is just a dumb API user here that sometimes get told > "nope" by the underlying libraries, whether due to crypto policy, FIPS > or whatever. I opened [1] to track this issue. It should be relatively straightforward to implement this. Sequoia already has first class policy objects that are consulted on every cryptograph operation [2]. What needs to be done is to read the Fedora system policy and configure the rpm-sequoia's policy object [3] appropriately. :) Neal [1] https://github.com/rpm-software-management/rpm-sequoia/issues/14 [2] https://docs.sequoia-pgp.org/sequoia_openpgp/policy/index.html https://docs.sequoia-pgp.org/sequoia_openpgp/policy/struct.StandardPolicy.html [3] https://github.com/rpm-software-management/rpm-sequoia/blob/main/src/lib.rs#L121 ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: F38 proposal: RPM Sequoia (System-Wide Change proposal)
On Fri, 14 Oct 2022 18:28:01 +0200, Simo Sorce wrote: > At this time, as far as I know, there is no OpenPGP work of any kind on > supporting PQC algorithms. The German BSI contracted MTG AG to design and implement PQC for OpenPGP. They presented their work at IETF 113, and at the OpenPGP email summit this past May. https://datatracker.ietf.org/meeting/113/materials/agenda-113-openpgp-01 > Furthermore the way we use signatures in RPM > really has no resemblance to the scenarios OpenPGP was built for. Could you elaborate on this, please. Thanks, Neal ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: rpm with sequoia pgp
Hi Dan, On Mon, 05 Sep 2022 14:18:05 +0200, Dan Čermák wrote: > "Neal H. Walfield" writes: > As Sequoia is written in Rust, what is your RISCV story? Fedora is (at > least that's my impression) a quite popular choice for RISCV boards, so > rpm working on RISCV would be crucial for us staying relevant. This is a valid concern, and one that I'm also worried about. According to this web page: https://fedoraproject.org/wiki/Architectures/RISC-V Fedora wants to support the RV64GC architecture, which I think corresponds to riscv64gc-unknown-linux-gnu. The Rust project indicates that riscv64gc-unknown-linux-gnu is a Tier 2 architecture: https://doc.rust-lang.org/nightly/rustc/platform-support.html FWIW, Fedora also supports armv7hl (armv7-unknown-linux-gnueabihf) and s390x-unknown-linux-gnu, which are also Tier 2 Rust architectures, but which have Rust packages: https://koji.fedoraproject.org/koji/buildinfo?buildID=1939157 So, I guess the bad news is that RISCV is not Tier 1, but the good news is that Tier 2 is already pretty good. Relatedly, I hear that Linux will start using Rust. I suspect that as that happens, a lot more resources will be invested in making sure Rust has good support on all of the platforms that Linux supports. Finally, rpm 4.18 will support both the internal OpenPGP parser and the Sequoia-based parser. So, if the Sequoia-based parser proves inadequate for some platforms (e.g., it doesn't compile or the test suite fails), Fedora can still fallback to the internal parser on that platforms. Note, though, that the internal OpenPGP parser is slated to be removed in 4.19: https://github.com/rpm-software-management/rpm/issues/1935 Neal ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: rpm with sequoia pgp
On Mon, 05 Sep 2022 10:12:23 +0200, Alexander Sosedkin wrote: > Mind the > https://docs.fedoraproject.org/en-US/packaging-guidelines/CryptoPolicies > > Will we need to introduce a configuration mechanism to limit algorithm > selection in Sequoia PGP? Or just wait untl it switches to OpenSSL? Good question. Sequoia has a flexible mechanism to describe its cryptographic policy: https://docs.sequoia-pgp.org/sequoia_openpgp/policy/struct.StandardPolicy.html There isn't yet a way to configure it using a configuration file, but that is doable. Here's the issue, fwiw: https://gitlab.com/sequoia-pgp/sequoia/-/issues/857 One potential issue is that OpenPGP fingerprints are computed using SHA-1. In practice this is not a security problem as fingerprints don't need collision resistance, just second pre-image resistance, which SHA-1 still has. The upcoming version of the OpenPGP specification specifies SHA2 256-based fingerprints https://datatracker.ietf.org/doc/html/draft-ietf-openpgp-crypto-refresh-06#section-5.5.4 But we won't be able to switch immediately: users would have to create new certificates, and old certificates would have to fall out of use. Neal ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: rpm with sequoia pgp
Hi Paul, Thanks for your comments. On Fri, 02 Sep 2022 20:21:21 +0200, Paul Wouters wrote: > On Fri, 2 Sep 2022, Neal H. Walfield wrote: > > > Note: Sequoia currently uses Nettle on Fedora, but there is ongoing > > work to port it to Sequoia to OpenSSL: > > I think this should be considered a blocker for changing gpg backends. That's a decision for Fedora. I have no strong preference. (For what it's worth, rpm doesn't use gpg. rpm has an internal OpenPGP backend, which was developed in house.) > > > > https://github.com/rpm-software-management/rpm/issues/2041#issuecomment-1219175000 > > > > Note2: There are lots of reasons to use Sequoia, but one user-visible > > reason is improved usability. When a user imports a certificate, > > Sequoia lints it and displays potential issues, or reasons why it > > can't be imported: > > > > > > https://github.com/rpm-software-management/rpm/issues/1974#issuecomment-1081779174 > > > > $ rpm --import peter-expired-backsig.pgp > > Certificate 251C20A67D942D45: > >Policy rejects subkey CB4F47D30C8C9CE1: Expired on 2020-05-08T05:11:51Z > >Certificate does not have any usable signing keys > > > > Whereas before rpm would just say: > > > > error: peter-expired-backsig.pgp: key 1 import failed. > > That seems like a fairly minor point to change backends and crypto > library for and could be something that can be fixed in the current > backend as well? I spent some time looking at and trying to improve rpm's OpenPGP implementation. It's quite hairy. See, for example, this issue: https://github.com/rpm-software-management/rpm/issues/2004 Even Panu (rpm's maintainer) does not have great confidence in the OpenPGP parser's robustness: I think the only safe assumption is to assume it a bug in rpm's parser. Shock horror :laughing: https://github.com/rpm-software-management/rpm/issues/2004#issuecomment-1096286416 If you want to have a look at the code, here's a good place to start: https://github.com/rpm-software-management/rpm/blob/d703160/rpmio/rpmpgp_internal.c#L965 I suspect that this hairiness is because the internal OpenPGP parser started as a minimal implementation to handle data generated by GnuPG when it was written about 20 years ago. Panu writes: https://github.com/rpm-software-management/rpm/pull/1813#discussion_r790681223 the rpm implementation strives to do the bare minimum to get by https://github.com/rpm-software-management/rpm/issues/1978#issuecomment-1080606598 The current "API" is ad-hoc stuff added over the course of 20 years, by people with not much OpenPGP experience. I'm sure it shows. And, over time it has grown in complexity to accommodate new requirements, like support for RFC 4880, and subkeys. Whatever the case, Panu doesn't want to invest more time into it: https://github.com/rpm-software-management/rpm/issues/1935 There's something seriously wrong when a significant percent of package manager development discussions is about OpenPGP specification and its interpretation in the RPM context. This is negatively impacting development of RPM "core business", to the point that this has to stop. There's exactly one way to stop it, and that's getting rid of the internal parser, one way or the other. Targeted for RPM 4.19 in 2023, and this also means that no major developments to the existing parser should be done, from here on it's strictly in critical fixes only -mode. Those are reasons against the internal OpenPGP implementation. But, I also want to briefly say why I (a co-founder of the Sequoia project), think that Sequoia is a good choice. In Sequoia we've spent a lot of time trying to get the little details right. In particular, we invested a lot of effort in certificate canonicalization, which is essential to making sure OpenPGP certificates are interpreted in a sane way. There is a nice write up of why this is hard by the author of PGPainless: https://blog.jabberhead.tk/2021/04/03/why-signature-verification-in-openpgp-is-hard/ When I first thought about signature verification in OpenPGP I thought “well, it cannot be that hard, right?”. In the end all you got to do is check if a signature was made by the given key and if that signature checks out (is cryptographically correct). Oh boy, was I wrong. (For the haters: yes, OpenPGP is complicated, but I suspect this type of complexity will be present in some form of another is all PKIs that support expirations, revocations, etc.) It's due to this infrastructure that Sequoia is so often able to return informative error messages that go to the root cause of the problem. While developing Sequoia, we didn't just rely on our interpretation of the RFC. We also looked at what other implementations were doing and tried to pus
rpm with sequoia pgp
Hi all, rpm 4.18 is on the horizon and includes a new OpenPGP backend based on Sequoia PGP. https://rpm.org/wiki/Releases/4.18.0 https://sequoia-pgp.org/ Thanks to Fabio Valentini (decathorpe) for packaging not only rpm-sequoia, but all of the Sequoia packages for Fedora. https://copr.fedorainfracloud.org/coprs/decathorpe/sequoia-test-builds/package/rust-rpm-sequoia/ With this note, I'd firstly like to make the Fedora community more aware of this project. (I don't think it has been mentioned here yet.) Second, although the internal OpenPGP backend is still the default backend, it will be removed in rpm 4.19: https://github.com/rpm-software-management/rpm/issues/1935 It is probably best to start the transition as soon as possible to work out any kinks. In that vein, I'd like to offer my help. Making this type of change needs to be done carefully. Perhaps these are questions or concerns. I'd like to hear them and respond to them. There is also technical work that needs to be done. I'm more of a developer than a packager, but if Fedora decides to use the Sequoia backend, I'd like to offer my help in any way I can. Note: Sequoia currently uses Nettle on Fedora, but there is ongoing work to port it to Sequoia to OpenSSL: https://github.com/rpm-software-management/rpm/issues/2041#issuecomment-1219175000 Note2: There are lots of reasons to use Sequoia, but one user-visible reason is improved usability. When a user imports a certificate, Sequoia lints it and displays potential issues, or reasons why it can't be imported: https://github.com/rpm-software-management/rpm/issues/1974#issuecomment-1081779174 $ rpm --import peter-expired-backsig.pgp Certificate 251C20A67D942D45: Policy rejects subkey CB4F47D30C8C9CE1: Expired on 2020-05-08T05:11:51Z Certificate does not have any usable signing keys Whereas before rpm would just say: error: peter-expired-backsig.pgp: key 1 import failed. Thanks, :) Neal ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
