F45 Change Proposal: Sequoia opengpgverify (self-contained)

Wiki - https://fedoraproject.org/wiki/Changes/Sequoia_opengpgverify Discussion thread - https://discussion.fedoraproject.org/t/f45-change-proposal-sequoia-opengpgverify-self-contained/197231 This is a proposed Change for Fedora Linux. This document represents a proposed Change. As part of the Changes process, proposals are publicly announced in order to receive community feedback. This proposal will only be implemented if approved by the Fedora Engineering Steering Committee. == Summary == Introduce a rpm macro <code>%openpgpverify</code> and update packages to use it instead of existing gnupg specific <code>%gpgverify</code>. The new macro will use standard OpenPGP implementation from Sequoia instead of GnuPG by default to provide support for Post Quantum Cryptography defined in the OpenPGP WG. This is part of gradual switching from GnuPG dependency. == Owner == * Name: [[User:jjelen| Jakub Jelen]] [[User:decathorpe | Fabio Valentini ]] * Email: jjelen@redhat.com, decathorpe AT gmail DOT com == Detailed Description == The GnuPG decided to fork the OpenPGP specification as LibrePGP to develop incompatible standard in 2023. Since then, the GnuPG 2.5.* versions (not present in Fedora) can create artifacts incompatible with current OpenPGP standard. We are observing the situation and the we believe Fedora project should embrace the OpenPGP standard developed within the IETF, which involves gradually switching from the GnuPG to other implementations where possible. We identified Sequoia-PGP as a good candidate as it implements the standard OpenPGP (including the RFC 9980 standardizing PQC). The Sequoia-PGP is already used as part of RPM to verify [https://sequoia-pgp.org/blog/2023/04/27/rpm-sequoia/ RPM signatures] since 2023, as well as in [https://src.fedoraproject.org/rpms/rust-podman-sequoia podman]. RPM also supports [https://github.com/rpm-software-management/rpm/blob/master/docs/man/rpmsign.1.scd#examples signing RPMs using Sequoia tools] since version 6.0 so adjusting the rpm macros is natural next step. == Feedback == == Benefit to Fedora == * Prevent vendor-lock-in in GnuPG ecosystem. * Follow IETF standardization * Improve security by providing developers with ability to use Post Quantum Cryptography to sign their artifacts. * Integrate better with the rest of the operating system by following system wide crypto policies. == Scope == * Proposal owners: * Create a new <code>%openpgpverify</code> macro using sqv CLI * Verify it works with existing artifacts in Fedora, fix/workaround/report possible issues. * Change <code>%gpgverify</code> rpm macro in existing spec files to use <code>%openpgpverify</code> where possible with proven packager or PRs * Other developers: Respond to possible issues/PRs in cases where this will not work out of the box. * Release engineering: [https://forge.fedoraproject.org/releng/tickets/issues #Releng issue number] * Policies and guidelines: The Packaging Guidelines should be updated to make use %openpgpverify macro by default. * Trademark approval: N/A (not needed for this Change) * Alignment with the Fedora Strategy: N/A == Upgrade/compatibility impact == No upgrade impact -- this involves just build system and development. Compatibility needs to be evaluated. There should not be any existing librePGP artifacts, but there might be some old GnuPG keys that will not pass stricter Sequoia checks. Identifying them will help increase security of the supply chain as insecure keys might allow getting forged artifacts to Fedora. == Early Testing (Optional) == Verify all packages that use <code>%gpgverify</code> macro work with <code>%openpgpverify</code>. == How To Test == * Have a dist git of a package with upstream tarball signed with GPG key * Update gpgverify BuildRequires to openpgpverify * Update %gpgverify macro to %openpgpverify * Verify the local package build works for you with `fedpkg local` or `fedpkg mockbuild` If not, review the log, key(ring) and report potential issues to the upstream developer or Sequoia developers. Do they use SHA1 in their certificate? Do they use small RSA key that could be broken by Quantum Computer in close future? == User Experience == This change should not affect user experience. == Dependencies == * rust-sequoia-sqv * gpgverify * other packages using gpgverify == Contingency Plan == * Contingency mechanism: (What to do? Who will do it?) N/A (not a System Wide Change) * Contingency deadline: N/A (not a System Wide Change) * Blocks release? N/A (not a System Wide Change) == Documentation == Fedora packaging guidelines need to be updated to reflect this change. https://docs.fedoraproject.org/en-US/packaging-guidelines/#_verifying_signatures N/A (not a System Wide Change) == Release Notes == Fedora is using Sequoia to by default to verify upstream tarball signatures during the build time. This allows upstreams to sign their artifacts using Quantum Resistant algorithms defined in the latest OpenPGP RFC 9980. -- Aoife Moloney Fedora Operations Architect Fedora Project Matrix: @amoloney:fedora.im IRC: amoloney -- _______________________________________________ devel-announce mailing list -- devel-announce@lists.fedoraproject.org To unsubscribe send an email to devel-announce-leave@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-announce@lists.fedoraproject.org Do not reply to spam, report it: https://forge.fedoraproject.org/infra/tickets/issues/new