[arch-dev-public] gnupg 2.3.1-1 pulled from [testing]
Yo! It seems like gnupg 2.3.1-1 was built and pushed to [testing] briefly before being removed. The reason from the removal is because there are changes to how gnupg verifies signatures that depends on the key UIDs being properly signed. In the case of my key, "foxboron@archlinux.org" is of marginal trust while "morten@linderud.pw" is fully trusted. Since packages are signed with "--sender foxboron@archlinux.org" gnupg cares about this trust level starting from 2.3.0-1. This results in failing signature checks if you have this package and attempt to fetch packages signed by me. Related issue: https://dev.gnupg.org/T4735 Why was this removed with no headsup? It caused a fair bit of confusion for a few people and the cause of this issue isn't very clear when packaged fail to verify. Ideally we should have pushed gnupg with an epoch? To testers: The best course of action is to downgrade the gnupg package to 2.2.27-1 from the package archive or your local package cache. https://archive.archlinux.org/packages/g/gnupg/ <sidenote> gnupg is terrible :) </sidenote> -- Morten Linderud PGP: 9C02FF419FECBE16
Hi Morten, Thanks for the summary. On Mon, 10 May 2021 at 13:31:13, Morten Linderud via arch-dev-public wrote:
Why was this removed with no headsup? It caused a fair bit of confusion for a few people and the cause of this issue isn't very clear when packaged fail to verify. Ideally we should have pushed gnupg with an epoch?
I removed the package after Jan informed me yesterday that the package is broken. Apologies for not making a public announcement; I should have send an email to our mailing lists. The package has two undocumented patches, one to remove a warning and another one that's required for pacman. I was not aware that pacman required a patched version of GnuPG and will work on porting/rebasing and documenting the patches before pushing a new build. When it comes to pushing with epoch, my understanding was that it is expected that packages break occasionally in [testing] and might get dropped. The recommendation for all [testing] users used to be to subscribe to arch-dev-public where dropped packages are (or at least should be) announced. Do we want to provide upgrade paths for broken packages in [testing]? Best, Lukas
On Tue, May 11, 2021 at 08:28:24AM -0400, Lukas Fleischer wrote:
Hi Morten,
Thanks for the summary.
Yoo! Thanks for explaining :)
On Mon, 10 May 2021 at 13:31:13, Morten Linderud via arch-dev-public wrote:
Why was this removed with no headsup? It caused a fair bit of confusion for a few people and the cause of this issue isn't very clear when packaged fail to verify. Ideally we should have pushed gnupg with an epoch?
I removed the package after Jan informed me yesterday that the package is broken. Apologies for not making a public announcement; I should have send an email to our mailing lists.
No worries. People started bugging me on IRC and there is now a thread on the subreddit as well. I thought I'd just send one before people started sending me personal emails about some weird conspiracies about compromised signing keys :p
The package has two undocumented patches, one to remove a warning and another one that's required for pacman. I was not aware that pacman required a patched version of GnuPG and will work on porting/rebasing and documenting the patches before pushing a new build.
Thanks! But it's probably a few more changes with the signing UIDs we need to account for. I believe Santiago and/or Jonas can explain but it would probably be better to share the package on the mailing list or throw it into staging so we can look at it before it enters testing.
When it comes to pushing with epoch, my understanding was that it is expected that packages break occasionally in [testing] and might get dropped. The recommendation for all [testing] users used to be to subscribe to arch-dev-public where dropped packages are (or at least should be) announced. Do we want to provide upgrade paths for broken packages in [testing]?
I'm not sure about if we traditionally drop packages from testing or do an epoch. I might be wrong and developers probably have a stronger opinion. Ideally testers should follow arch-dev-public closely. I thought it was mentioned somewhere but it apparently hasn't been on the testing team wikipage. NetSysFire has added a note for it :) https://wiki.archlinux.org/title/Arch_Testing_Team Thanks! -- Morten Linderud PGP: 9C02FF419FECBE16
On 11/5/21 10:28 pm, Lukas Fleischer via arch-dev-public wrote:
Hi Morten,
Thanks for the summary.
On Mon, 10 May 2021 at 13:31:13, Morten Linderud via arch-dev-public wrote:
Why was this removed with no headsup? It caused a fair bit of confusion for a few people and the cause of this issue isn't very clear when packaged fail to verify. Ideally we should have pushed gnupg with an epoch?
I removed the package after Jan informed me yesterday that the package is broken. Apologies for not making a public announcement; I should have send an email to our mailing lists.
The package has two undocumented patches, one to remove a warning and another one that's required for pacman. I was not aware that pacman required a patched version of GnuPG and will work on porting/rebasing and documenting the patches before pushing a new build.
Our patch documentation policy is non-existent, but you'd have to assume that revert was in the package for a reason. Looking in the SVN history: https://github.com/archlinux/svntogit-packages/commit/ce66f685cf14e94c9f1aa6...
When it comes to pushing with epoch, my understanding was that it is expected that packages break occasionally in [testing] and might get dropped. The recommendation for all [testing] users used to be to subscribe to arch-dev-public where dropped packages are (or at least should be) announced. Do we want to provide upgrade paths for broken packages in [testing]?
And announcement on arch-dev-public has been enough previously. No need for an epoch build. I'd also like to query why 2.3.x was packaged at all? From the 2.3 series announcement: "We are pleased to announce the availability of a new GnuPG release: version 2.3.0. This release marks the start of public testing releases eventually leading to a new stable version 2.4." It seems that we should stay with 2.2.x until 2.4 is released, and the out-of-date flag should be ignored. That will give time to fix the fallout from this change (which is the root cause of the issue that was noticed): https://dev.gnupg.org/T4735 Allan
On Tue, May 11, 2021 at 11:15:50PM +1000, Allan McRae via arch-dev-public wrote:
I'd also like to query why 2.3.x was packaged at all? From the 2.3 series announcement:
"We are pleased to announce the availability of a new GnuPG release: version 2.3.0. This release marks the start of public testing releases eventually leading to a new stable version 2.4."
It seems that we should stay with 2.2.x until 2.4 is released, and the out-of-date flag should be ignored. That will give time to fix the fallout from this change (which is the root cause of the issue that was noticed): https://dev.gnupg.org/T4735
Consider the announcement for the 2.3.1 release: "Although some bugs might linger in the 2.3 versions, they are intended to replace the 2.2 series." I'm not sure if the note was only intended for the 2.3.0 release? https://lists.gnupg.org/pipermail/gnupg-announce/2021q2/000459.html -- Morten Linderud PGP: 9C02FF419FECBE16
On 11/5/21 11:20 pm, Morten Linderud via arch-dev-public wrote:
On Tue, May 11, 2021 at 11:15:50PM +1000, Allan McRae via arch-dev-public wrote:
I'd also like to query why 2.3.x was packaged at all? From the 2.3 series announcement:
"We are pleased to announce the availability of a new GnuPG release: version 2.3.0. This release marks the start of public testing releases eventually leading to a new stable version 2.4."
It seems that we should stay with 2.2.x until 2.4 is released, and the out-of-date flag should be ignored. That will give time to fix the fallout from this change (which is the root cause of the issue that was noticed): https://dev.gnupg.org/T4735
Consider the announcement for the 2.3.1 release:
"Although some bugs might linger in the 2.3 versions, they are intended to replace the 2.2 series."
I'm not sure if the note was only intended for the 2.3.0 release?
https://lists.gnupg.org/pipermail/gnupg-announce/2021q2/000459.html
Well, I'm glad upstream are consistent with their release announcements!
Em maio 11, 2021 9:28 Lukas Fleischer via arch-dev-public escreveu:
Hi Morten,
Thanks for the summary.
On Mon, 10 May 2021 at 13:31:13, Morten Linderud via arch-dev-public wrote:
Why was this removed with no headsup? It caused a fair bit of confusion for a few people and the cause of this issue isn't very clear when packaged fail to verify. Ideally we should have pushed gnupg with an epoch?
I removed the package after Jan informed me yesterday that the package is broken. Apologies for not making a public announcement; I should have send an email to our mailing lists.
The package has two undocumented patches, one to remove a warning and another one that's required for pacman. I was not aware that pacman required a patched version of GnuPG and will work on porting/rebasing and documenting the patches before pushing a new build.
When it comes to pushing with epoch, my understanding was that it is expected that packages break occasionally in [testing] and might get dropped. The recommendation for all [testing] users used to be to subscribe to arch-dev-public where dropped packages are (or at least should be) announced. Do we want to provide upgrade paths for broken packages in [testing]?
I don't mind the occasional broken package on [testing] get pulled out. I mean, we must do our best to not intentionally break it, but we can't make sure everything is working, hence we have testing. Just that, on this case, an email would've been nice. Regards, Giancarlo Razzolini
participants (4)
-
Allan McRae
-
Giancarlo Razzolini
-
Lukas Fleischer
-
Morten Linderud