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:
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)
Announced in https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/B4VKWKYWYRVYGK6XBGPMKDADLQAAJBOG/
Log in to comment on this ticket.