Wiki - https://fedoraproject.org/wiki/Changes/Fix_limitations_in_gpgverify Discussion thread - https://discussion.fedoraproject.org/t/f43-change-proposal-fix-limitations-in-gpgverify-system-wide/145920 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 == <code>gpgverify</code> is a wrapper around <code>gpgv</code> designed to make it easy for packagers to do source file verification correctly. By accident it has some limitations that a few unusual packages have to work around. This change removes those limitations, reducing the need for workarounds. == Owner == * Name: [[User:Rombobeorn| Björn Persson]] * Email: [mailto:bjorn@xxxxxxxxxxxxxxxxxxxx Bjorn@Rombobjörn.se] == Current status == [[Category:ChangeReadyForWrangler]] [[Category:SystemWideChange]] <!-- It's not allowed to be self-contained because the change owner isn't a maintainer of the package. --> * Targeted release: [https://docs.fedoraproject.org/en-US/releases/f43/ Fedora Linux 43] * Last updated: <!-- this is an automatic macro — you don't need to change this line --> {{REVISIONYEAR}}-{{REVISIONMONTH}}-{{REVISIONDAY2}} * [<link to devel-announce post will be added by Wrangler> Announced] * [<will be assigned by the Wrangler> Discussion thread] * FESCo issue: <will be assigned by the Wrangler> * Tracker bug: <will be assigned by the Wrangler> * Release notes tracker: <will be assigned by the Wrangler> == Detailed Description == <code>gpgverify</code> was originally written to handle the common cases described in [https://docs.fedoraproject.org/en-US/packaging-guidelines/#_source_file_verification the source file verification policy]. Since then a few unusual cases have turned up that nobody thought of when the policy was written: <ul><li><p>Some upstream developers publish their OpenPGP keys as separate files instead of a combined keyring. Nginx is one example. It's a good practice that should be encouraged. Listing each key as a separate source file in a package makes it easy to see in the revision history whether a single key has been added or the whole set of keys has been replaced.</p> <p>The old <code>gpgverify</code> accepts only one keyring, so separate keys must be combined into a single file to be passed to <code>gpgverify</code>. There's no reason to make packagers do that. <code>gpgv</code> accepts multiple keyrings. The new <code>gpgverify</code> can also accept multiple keyrings and pass them to <code>gpgv</code>.</p></li> <li><p>Some upstream developers publish clearsigned files of checksums of tarballs instead of detached signatures of the tarballs. It would be easier for everybody if they'd skip the intermediate checksum and just sign their tarballs, but since this occurs, we should do what we can to make it easy for packagers to verify such signatures. This is important especially because of a treacherous pitfall: It's easy to use GnuPG wrong so that attackers can add unsigned text to a clearsigned file and make it seem like the whole file is verified.</p> <p>The old <code>gpgverify</code> requires a detached signature, so any package that needs to verify a clearsigned file has to bypass <code>gpgverify</code> and invoke <code>gpgv</code> directly. <code>git-lfs.spec</code> tries to do that, and gets it wrong, so it's vulnerable to spoofing. The new <code>gpgverify</code> can verify clearsigned files. If the signature is not detached, it insists on writing the verified data to an output file. Further processing shall trust only the verified contents of the output file, not the clearsigned file.</p></li> <li><p><code>gpgv</code> accepts keys in the keybox format. The new <code>gpgverify</code> also accepts them, in case anyone needs to use one.</p></li></ul> Some people might think these limitations are unimportant because they don't affect many packages. That's not how security works. Security requires closing <em>every</em> loophole. == Feedback == There has been no reaction whatsoever in the year and a half [https://src.fedoraproject.org/rpms/redhat-rpm-config/pull-request/261 the merge request] has been open. == Benefit to Fedora == Maintainers of a few packages will be able to remove workarounds for the old <code>gpgverify</code>'s limitations. Preventing a loophole in the signature verification in even a single package prevents attackers from using that package as an attack vector, thus improving security for everybody. == Scope == * Proposal owners: ** Implement the improvements in <code>gpgverify</code> – done. ** Write testcases – done. * Other developers: ** Maintainers of <code>redhat-rpm-config</code>: [https://src.fedoraproject.org/rpms/redhat-rpm-config/pull-request/261 Merge the improvements]. * Release engineering: N/A * Policies and guidelines: No change to policies is proposed. The Packaging Guidelines don't currently cover the unusual cases addressed by these improvements, and it can continue to be so. If, however, there is a desire for the Packaging Guidelines to contain complete instructions for every possible case, then some amendments will be needed. * Trademark approval: N/A (not needed for this Change) * Alignment with the Fedora Strategy: The Community Operations 2.0 Initiative, which aims to address friction in the contribution process, may be relevant. == Upgrade/compatibility impact == These improvements are fully backward-compatible. No currently working spec file will break. == How To Test == Testcases are included in [https://src.fedoraproject.org/rpms/redhat-rpm-config/pull-request/261 the merge request]. Those same testcases [https://www.rombobjörn.se/gpgverify-tests/ are also available for manual testing]. Run them through <code>rpmbuild --rebuild</code>. Those with “bad” or “invalid” in the name shall fail to build. All the others shall build successfully. == User Experience == Tightening the supply chain security will slightly decrease the risk that users will have their computers breached through compromised Fedora packages. == Dependencies == As the author isn't a maintainer of <code>redhat-rpm-config</code>, the change depends on a maintainer [https://src.fedoraproject.org/rpms/redhat-rpm-config/pull-request/261 merging the improvements]. == Contingency Plan == * Contingency mechanism: The maintainers of <code>redhat-rpm-config</code> can revert the commits and rebuild, should it become necessary. * Contingency deadline: Before any mass rebuild (because hypothetically, if <code>gpgverify</code> would break, it could cause many packages to fail to build). * Blocks release? Yes. (If it would cause important packages to fail to build, that is. But the code is already written and tested.) == Documentation == The help text that <code>/usr/lib/rpm/redhat/gpgverify --help</code> prints has been updated to explain the new parameters. One can also see the help text by simply reading [https://src.fedoraproject.org/fork/rombobeorn/rpms/redhat-rpm-config/raw/gpgverify/f/gpgverify the file]. == Release Notes == N/A -- Aoife Moloney Fedora Operations Architect Fedora Project Matrix: @amoloney:fedora.im IRC: amoloney -- _______________________________________________ devel-announce mailing list -- devel-announce@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-announce-leave@xxxxxxxxxxxxxxxxxxxxxxx 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@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue -- _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx 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@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
