F43 Change Proposal: Fix limitations in `gpgverify` (system-wide)

Project Discussion Change Proposals
,
1

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.

wiki
Announced

:link: 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.

:link: Owner

:link: 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.

:link: Feedback

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

:link: 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.

:link: 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.

:link: Upgrade/compatibility impact

These improvements are fully backward-compatible. No currently working spec file will break.

:link: 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.

:link: User Experience

Tightening the supply chain security will slightly decrease the risk that users will have their computers breached through compromised Fedora packages.

:link: Dependencies

As the author isn’t a maintainer of redhat-rpm-config, the change depends on a maintainer merging the improvements.

:link: 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.)

:link: 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.

:link: Release Notes

N/A

Last edited by @amoloney 2025-02-24T17:40:20Z

Last edited by @amoloney 2025-02-24T17:40:20Z

2

How do you feel about the proposal as written?

  • Strongly in favor
  • In favor, with reservations
  • Neutral
  • Opposed, but could be convinced
  • Strongly opposed
0 voters

If you are in favor but have reservations, or are opposed but something could change your mind, please explain in a reply.

We want everyone to be heard, but many posts repeating the same thing actually makes that harder. If you have something new to say, please say it. If, instead, you find someone has already covered what you’d like to express, please simply give that post a :heart: instead of reiterating. You can even do this by email, by replying with the heart emoji or just “+1”. This will make long topics easier to follow.

Please note that this is an advisory “straw poll” meant to gauge sentiment. It isn’t a vote or a scientific survey. See About the Change Proposals category for more about the Change Process and moderation policy.

3

The gpgverify stuff needs to be split out into its own package, then redhat-rpm-config can depend on it. Or gnupg2 can grow a Requires: (gpgverify if rpm-build) stanza.

4

This change proposal has now been submitted to FESCo with ticket #3373 for voting.

To find out more, please visit our Changes Policy documentation.

5

I don’t like the approach of asking for a lot of additional work as a prerequisite for a medium-sized fix. I don’t think this should be a requirement.

But also, I’m not sure if we’d want to do this anyway. gpgverify has so far had exactly two commits. So it’s a very low-maintenance code. Splitting it out to a separate project, creating a repo for that, going through review, creates a lot of additional work. If we were to reap the benefits of this by doing a lot of development on the code, that’d be reasonable. But once we merge the new stuff, it’s very likely to go dormant again.

It seems that the real blocker was that redhat-rpm-config pull request didn’t get a review. But we can’t solve this by splitting things up between more repos.

6

Having test cases and other things turns it a “simple script bundled with redhat-rpm-config” into “project expecting to be expanded and churn with contributions”. This is the point where I think it’s worth splitting out.

7

Yes, I expect it to just continue working once these limitations are fixed. It depends on Bash, Coreutils, Grep and GnuPG, all of which are very stable and dependable. A need for some other fix could of course arise, but not a lot.

I don’t expect any churn, except maybe in the testsuite itself, as I don’t know how stable that continuous integration infrastructure is. I tried to guess why the merge request was being ignored, and thought maybe you guys were worried about regressions. In that case a testsuite would show that the existing functionality still works. Plus the Changes policy demands testing instructions.

That said, I can make a gpgverify package, if the Fedora Project wants to trust me with the power to make unchecked changes to this security-critical component.

If it would become a separate package, then the correct design would be to write “BuildRequires: gpgverify” in the spec files instead of “BuildRequires: gnupg2”. The gpgverify package would then pull in gnupg2 as the dependency it actually is, and no dependency would need to be added to redhat-rpm-config.

That would require a change to the Packaging Guidelines, and a provenpackager would need to update all the spec files. If we can’t coordinate all those changes, then I suppose redhat-rpm-config depending on gpgverify would be an acceptable workaround.

I’ll wait to see if more than one person wants a separate package before I start working on a review request.

1 Like
8

I would probably add the dependency anyway. No reason not to.

I actually expect that now that we have a test suite, eventually we’d probably attempt to support Sequoia PGP as a backend since that is what RPM now uses and it’s already in the build environment.