#3373 Change: Fix limitations in gpgverify
Closed: Accepted 16 days ago by fale. Opened 2 months ago by amoloney.

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.

Owners, do not implement this work until the FESCo vote has explicitly ended.
The Fedora Program Manager will create a tracking bug in Bugzilla for this Change, which is your indication to proceed. See the FESCo ticket policy and the Changes policy for more information.

REMINDER: This ticket is for FESCo members to vote on the proposal. Further discussion should happen in the Discourse discussion linked above. Additional discussion may happen on the Fedora Devel mailing list.


Hum, no response to https://discussion.fedoraproject.org/t/f43-change-proposal-fix-limitations-in-gpgverify-system-wide/145920/3
?

ie, the idea of splitting this out into a seperate package that redhat-rpm-config then pulls in?

Kevin Fenzi wrote:

Hum, no response to https://discussion.fedoraproject.org/t/f43-change-pro=
posal-fix-limitations-in-gpgverify-system-wide/145920/3
?

The Discourse post didn't come to my inbox. This Pagure post did.

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 =E2=80=9CBuildRequires: gpgverify=E2=80=9D in the spec files inste=
ad of
=E2=80=9CBuildRequires: gnupg2=E2=80=9D. The gpgverify package would then p=
ull 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.

The discussion on discussion.fp.o seems to be finished.

+1 to the proposal

@ngompa are you willing to merge the PR? since you're one of the redhat-rpm-config maintainers. If you are then I'm +1 on this.

I've asked that this get turned into a separate package since it has a lot of extra stuff like tests and such. Once it is, I will be adding it as a conditional dependency to redhat-rpm-config, like so:

Requires: (gpgverify if gnupg2)

In the future, I expect it to be ported to sequoia pgp, and then I will unconditionally pull it in for redhat-rpm-config.

Looks like Neal's comments have not been addressed, so I'll treat that "unaddressed request for changes" as equivalent to a negative vote and add it to today's agenda.

This was discussed during today's meeting:

  • AGREED: Change is approved with the modification that gpgverify will become a separate package. (+6, 1, -0) (@decathorpe:fedora.im, 17:58:07)
  • INFO: The Change Proposal document will be updated accordingly. (@decathorpe:fedora.im, 17:58:26)

I have reworked the change page. A couple of links remain to be updated when there is a new package to point to, but I think the new form of the proposal is ready if you want to discuss it again.

+1 to the revised proposal

Hi FESCo members, do you want to vote again on the updated proposal or will I take this as accepted as the recommended steps have been completed?

Thanks,
Aoife

Change is approved with the modification that gpgverify will become a separate package.

I think this implies that we don't want to vote again, but I'd need to read the meeting minutes to be sure ... but I'm fine with saying "this is what was agreed on, and it was already approved".

Yup, I think we can consider it as such.

Fabio Valentini wrote:

I think this implies that we don't want to vote again, but I'd need to re=
ad the meeting minutes to be sure ... but I'm fine with saying "this is wha=
t was agreed on, and it was already approved".

In the summary you posted to the devel list, you wrote "the Proposal
will be adapted and discussed again when ready". That's why I mentioned
that the proposal is ready. If another vote isn't needed, that's fine
by me. Meanwhile, this looks to me like three votes in favor of the
revised proposal.

I'm good with the new version. +1

Right, sorry about the confusion.

+1 to the new version.

+1 on the new version

APPROVED (+6, 0, -0)

Metadata Update from @fale:
- Issue close_status updated to: Accepted
- Issue status updated to: Closed (was: Open)

16 days ago

Log in to comment on this ticket.

Metadata