Re: rpm with sequoia pgp
On 9/6/22 23:10, Simo Sorce wrote: On Tue, 2022-09-06 at 11:09 +0300, Panu Matilainen wrote: On 9/2/22 17:31, Neal H. Walfield wrote: 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 While that was the initial goal, I suspect we may have to stretch this a bit. I think we'll first need a release where the upstream default is something else, and then in the next release we can actually look at axing it. 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. Since rpm 4.18 gained the Sequoia support afterall, we can and should look into swapping over in Fedora 38. That'll help sorting out any rough edges and make it easier to eventually swap the default in upstream as well. We probably need to do this with a change process as anything rpm-related tends to be system/distro wide in a sense (see below) Once the dust from 4.18 has settled (final is expected in a couple of weeks) we can start digging into this, although nothing prevents starting with other "paperwork" etc. 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 This may well be a blocker on Fedora level, in part to keep container etc images small but also for distro crypto policies and FIPS (neither of which nettle supports AIUI). With my Crypto Team hat on I do not see this as a blocker for Fedora in the short term, we can start with nettle and then move to OpenSSL later. For RHEL we may prefer OpenSSL for various reasons above, but I would note that although we do not certify nettle directly under FIPS we do indirectly as part of GnuTLS, so it is certainly tested cryptography. In fact nettle might be a slightly better choice in some cases for container images because it is much smaller than OpenSSL. Yup. My assumption was that since openssl will be pulled in "anyway", anything else will be seen as unwanted size increase. But, I hadn't realized nettle is *that* much smaller. Finally nettle could even be statically built into sequoia (together with gmp) if we need even smaller footprint or we are concerned about potential rpm breakage during upgrades. I am not saying we want to do this, but it is an option that OpenSSL 3 won't provide as easily. Ack. Highly useful info this all, thanks! - Panu - Simo. ___ 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 Tue, 2022-09-06 at 11:09 +0300, Panu Matilainen wrote: > On 9/2/22 17:31, Neal H. Walfield wrote: > > 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 > > While that was the initial goal, I suspect we may have to stretch this a > bit. I think we'll first need a release where the upstream default is > something else, and then in the next release we can actually look at > axing it. > > > > > 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. > > Since rpm 4.18 gained the Sequoia support afterall, we can and should > look into swapping over in Fedora 38. That'll help sorting out any rough > edges and make it easier to eventually swap the default in upstream as > well. We probably need to do this with a change process as anything > rpm-related tends to be system/distro wide in a sense (see below) > > Once the dust from 4.18 has settled (final is expected in a couple of > weeks) we can start digging into this, although nothing prevents > starting with other "paperwork" etc. > > > 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 > > This may well be a blocker on Fedora level, in part to keep container > etc images small but also for distro crypto policies and FIPS (neither > of which nettle supports AIUI). With my Crypto Team hat on I do not see this as a blocker for Fedora in the short term, we can start with nettle and then move to OpenSSL later. For RHEL we may prefer OpenSSL for various reasons above, but I would note that although we do not certify nettle directly under FIPS we do indirectly as part of GnuTLS, so it is certainly tested cryptography. In fact nettle might be a slightly better choice in some cases for container images because it is much smaller than OpenSSL. Finally nettle could even be statically built into sequoia (together with gmp) if we need even smaller footprint or we are concerned about potential rpm breakage during upgrades. I am not saying we want to do this, but it is an option that OpenSSL 3 won't provide as easily. Simo. -- Simo Sorce RHEL Crypto Team Red Hat, Inc ___ 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 9/2/22 17:31, Neal H. Walfield wrote: 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 While that was the initial goal, I suspect we may have to stretch this a bit. I think we'll first need a release where the upstream default is something else, and then in the next release we can actually look at axing it. 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. Since rpm 4.18 gained the Sequoia support afterall, we can and should look into swapping over in Fedora 38. That'll help sorting out any rough edges and make it easier to eventually swap the default in upstream as well. We probably need to do this with a change process as anything rpm-related tends to be system/distro wide in a sense (see below) Once the dust from 4.18 has settled (final is expected in a couple of weeks) we can start digging into this, although nothing prevents starting with other "paperwork" etc. 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 This may well be a blocker on Fedora level, in part to keep container etc images small but also for distro crypto policies and FIPS (neither of which nettle supports AIUI). - Panu - ___ 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, Sep 5, 2022 at 2:18 PM Dan Čermák wrote: > > Hi Neal, > > "Neal H. Walfield" writes: > > > 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/ > > 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. I don't think architecture support is a problem. This might have been an issue when Rust was relatively new, but the list of supported targets is pretty big now: https://doc.rust-lang.org/nightly/rustc/platform-support.html For example, RISC-V (riscv64gc-unknown-linux-gnu) is supported by the Rust toolchain at the same level (Tier 2) as three other architectures we have (armv7hl / armv7-unknown-linux-gnueabihf, ppc64le / powerpc64le-unknown-linux-gnu, s390x / s390x-unknown-linux-gnu). Only x86 (x86_64-unknown-linux-gnu / i686-unknown-linux-gnu) and aarch64 (aarch64-unknown-linux-gnu) have better support (Tier 1). Fabio ___ 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 Neal, "Neal H. Walfield" writes: > 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/ 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. Cheers, Dan ___ 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 push the whole ecosystem forward. This is demonstrated through Justus' work on the OpenPGP interoperability test suite: https://tests.sequoia-pgp.org/ Please share any
Re: rpm with sequoia pgp
On Mon, Sep 5, 2022 at 10:55 AM Fabio Valentini wrote: > > On Mon, Sep 5, 2022 at 10:12 AM Alexander Sosedkin > wrote: > > > > Quoting Neal H. Walfield (2022-09-02 16:31:18) > > > 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 > > > > 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? > > Isn't this handled at the level of the crypto library? That's my question, really: does it need extra configuration generated or will it just attempt a low-level library operation and fail gracefully when it finds the operations blocked? > OpenPGP uses nettle for cryptography purposes, shouldn't *that* follow > system crypto policy, just as OpenSSL does? > For example, I don't see anything related to crypto policies in the > gnupg2 package, either. Unfortunately, nettle and gnupg2 don't follow crypto-policies (yet?). It's only beginning to expand beyond networking protocols (TLS/SSH/KRB...). ___ 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, Sep 5, 2022 at 10:12 AM Alexander Sosedkin wrote: > > Quoting Neal H. Walfield (2022-09-02 16:31:18) > > 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 > > 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? Isn't this handled at the level of the crypto library? OpenPGP uses nettle for cryptography purposes, shouldn't *that* follow system crypto policy, just as OpenSSL does? For example, I don't see anything related to crypto policies in the gnupg2 package, either. Fabio ___ 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
Quoting Neal H. Walfield (2022-09-02 16:31:18) > 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 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? > ... ___ 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 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. 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? Of course if upstream rpm is moving, I think fedora should do so as well to keep in line with upstream, but to me that really does imply not using nettle but using openssl. Paul ___ 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 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
