From Fedora Project Wiki

Fix limitations in gpgverify

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

Detailed Description

Functional Changes

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.

Packaging Changes

Whereas the old gpgverify is included in redhat-rpm-config, the new gpgverify will be a separate package. The shellscript and the RPM macro will be removed from redhat-rpm-config. The new package will depend only on Bash, Coreutils, Grep and GnuPG.

Requires: (gpgverify if gnupg2)” will be added to redhat-rpm-config to keep existing spec files working. This dependency is technically backwards, but otherwise it would be necessary to make a coordinated change from “gnupg2” to “gpgverify” in every spec file that verifies a signature.

Feedback

It was requested that gpgverify be moved from redhat-rpm-config to a separate package. Fesco decided that they preferred that approach. This proposal has been reworked accordingly.

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.
    • Make a gpgverify package – done.
  • Maintainers of redhat-rpm-config: Remove the shellscript and the RPM macro and add the Requires tag when the new package is available in the repository – done.
  • Other developers: To be technically correct, spec files that verify signatures should be updated to “BuildRequires: gpgverify”. This doesn't need to be done before the contingency deadline. “Requires: (gpgverify if gnupg2)” in redhat-rpm-config will keep things working, and spec files can be updated piecemeal.
  • Release engineering: N/A
  • Policies and guidelines: The Packaging Guidelines should be updated from “BuildRequires: gnupg2” to “BuildRequires: gpgverify” – done.
  • 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 for gating are included in the Git repository. 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 removing gpgverify from redhat-rpm-config and adding the Requires tag.

Contingency Plan

  • Contingency mechanism:
    • In case of a problem with the functional changes, the new package can be changed to include the old version of the shellscript.
    • In case of a problem with the packaging changes, the maintainers of redhat-rpm-config can revert the change to that package.
  • 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/libexec/gpgverify --help (formerly /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