From Fedora Project Wiki

Fix limitations in gpgverify

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

gpgverify is a wrapper around gpgv 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

Current status

  • Targeted release: Fedora Linux 43
  • Last updated: 2025-02-19
  • [<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

gpgverify was originally written to handle the common cases described in the source file verification policy. Since then a few unusual cases have turned up that nobody thought of when the policy was written:

  • 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.

    The old gpgverify accepts only one keyring, so separate keys must be combined into a single file to be passed to gpgverify. There's no reason to make packagers do that. gpgv accepts multiple keyrings. The new gpgverify can also accept multiple keyrings and pass them to gpgv.

  • 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.

    The old gpgverify requires a detached signature, so any package that needs to verify a clearsigned file has to bypass gpgverify and invoke gpgv directly. git-lfs.spec tries to do that, and gets it wrong, so it's vulnerable to spoofing. The new gpgverify 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.

  • gpgv accepts keys in the keybox format. The new gpgverify also accepts them, in case anyone needs to use one.

Some people might think these limitations are unimportant because they don't affect many packages. That's not how security works. Security requires closing every loophole.

Feedback

There has been no reaction whatsoever in the year and a half the merge request has been open.

Benefit to Fedora

Maintainers of a few packages will be able to remove workarounds for the old gpgverify'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 gpgverify – done.
    • Write testcases – done.
  • Other developers:
  • 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 the merge request. Those same testcases are also available for manual testing. Run them through rpmbuild --rebuild. 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 redhat-rpm-config, the change depends on a maintainer merging the improvements.

Contingency Plan

  • Contingency mechanism: The maintainers of redhat-rpm-config can revert the commits and rebuild, should it become necessary.
  • Contingency deadline: Before any mass rebuild (because hypothetically, if gpgverify 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 /usr/lib/rpm/redhat/gpgverify --help prints has been updated to explain the new parameters. One can also see the help text by simply reading the file.

Release Notes

N/A

Retrieved from "https://fedoraproject.org/w/index.php?title=Changes/Fix_limitations_in_gpgverify&oldid=731153"