[arch-general] Corrupt Package (confirmed 2 servers) dovecot, jansson, python2-pillow
All,
Encountered corrupt packages tonight and confirmed by redownload from 2 different servers:
Packages (3) dovecot-2.3.0-2 jansson-2.10-3 python2-pillow-5.0.0-1
Total Download Size: 3.49 MiB Total Installed Size: 13.69 MiB Net Upgrade Size: 0.55 MiB
:: Proceed with installation? [Y/n] :: Retrieving packages... dovecot-2.3.0-2-x86_64 3.0 MiB 2.58M/s 00:01 [########################################] 100% jansson-2.10-3-x86_64 37.1 KiB 5.18M/s 00:00 [########################################] 100% python2-pillow-5.0.0-1-x86_64 497.6 KiB 5.86M/s 00:00 [########################################] 100% (3/3) checking keys in keyring [########################################] 100% (3/3) checking package integrity [########################################] 100% error: dovecot: signature from "Eli Schwartz eschwartz@archlinux.org" is marginal trust :: File /var/cache/pacman/pkg/dovecot-2.3.0-2-x86_64.pkg.tar.xz is corrupted (invalid or corrupted package (PGP signature)). Do you want to delete it? [Y/n] error: jansson: signature from "Eli Schwartz eschwartz@archlinux.org" is marginal trust :: File /var/cache/pacman/pkg/jansson-2.10-3-x86_64.pkg.tar.xz is corrupted (invalid or corrupted package (PGP signature)). Do you want to delete it? [Y/n] error: python2-pillow: signature from "Eli Schwartz eschwartz@archlinux.org" is marginal trust :: File /var/cache/pacman/pkg/python2-pillow-5.0.0-1-x86_64.pkg.tar.xz is corrupted (invalid or corrupted package (PGP signature)). Do you want to delete it? [Y/n] error: failed to commit transaction (invalid or corrupted package (PGP signature)) Errors occurred, no packages were upgraded.
Hi David,
I just tried to download the dovecot package and go no errors (from [1])
error: jansson: signature from "Eli Schwartz eschwartz@archlinux.org" is
marginal trust
The error means that your pacman keyring knows Eli's key but has no trustlevel associated to it (have you tried refreshing the keys or reinstalling the archlinux-keyring package?). Eli's key has been recently added to the keyring and may not be up to date with the signatures.
[1] https://mirror.fra10.de.leaseweb.net/
Best
Simon
On 02/11/2018 04:42 AM, Simon Doppler wrote:
The error means that your pacman keyring knows Eli's key but has no trustlevel associated to it (have you tried refreshing the keys or reinstalling the archlinux-keyring package?). Eli's key has been recently added to the keyring and may not be up to date with the signatures.
I refreshed the keylist with pacman-key no help, I finally just tagged TrustAll at the end of the line in packman.conf and it worked fine. There are screwed up signatures there.
On Sun, 11 Feb 2018 06:33:56 -0600 "David C. Rankin" drankinatty@suddenlinkmail.com wrote:
On 02/11/2018 04:42 AM, Simon Doppler wrote:
The error means that your pacman keyring knows Eli's key but has no trustlevel associated to it (have you tried refreshing the keys or reinstalling the archlinux-keyring package?). Eli's key has been recently added to the keyring and may not be up to date with the signatures.
I refreshed the keylist with pacman-key no help, I finally just tagged TrustAll at the end of the line in packman.conf and it worked fine. There are screwed up signatures there.
The issue is in your local keyring. Check all of the Arch Master Keys, make sure they're all signed by your local master key.
On 02/11/2018 07:09 AM, Doug Newgard via arch-general wrote:
I refreshed the keylist with pacman-key no help, I finally just tagged TrustAll at the end of the line in packman.conf and it worked fine. There are screwed up signatures there.
The issue is in your local keyring. Check all of the Arch Master Keys, make sure they're all signed by your local master key.
Can someone please explain why this key trust issue happened? In the past 7 years, running 10+ Arch boxes I have never had to adjust the trust on any key within the arch-keyring. Why all of a sudden, and why on only one box, did I have to --lsign-key for the eschwartz93 key? That is why this seemed so bizarre.
I have 5 other arch boxes running and updated and none of them experienced this problem. Only my spare laptop that I had not run/updated since last month showed this behavior.
For all other boxes this had been seamless (and that is a good thing). Is this some known random behavior that if you don't update between time A and time B, then you are likely to have to manually set the trust on any new keys added to the web-of-trust between points A & B?
I'm just trying to figure out what happened and what to expect in the future.
On 02/11/2018 05:22 PM, David C. Rankin wrote:
On 02/11/2018 07:09 AM, Doug Newgard via arch-general wrote:
I refreshed the keylist with pacman-key no help, I finally just tagged TrustAll at the end of the line in packman.conf and it worked fine. There are screwed up signatures there.
The issue is in your local keyring. Check all of the Arch Master Keys, make sure they're all signed by your local master key.
Can someone please explain why this key trust issue happened? In the past 7 years, running 10+ Arch boxes I have never had to adjust the trust on any key within the arch-keyring. Why all of a sudden, and why on only one box, did I have to --lsign-key for the eschwartz93 key? That is why this seemed so bizarre.
Obviously, because I've hacked you...
For all other boxes this had been seamless (and that is a good thing). Is this some known random behavior that if you don't update between time A and time B, then you are likely to have to manually set the trust on any new keys added to the web-of-trust between points A & B?
I'm just trying to figure out what happened and what to expect in the future.
Periodically, new Trusted Users are added to the team. When that happens, there is an update to the archlinux-keyring package, so you need to either update the keyring and then update packages that depend on the new key, or allow pacman to automatically import the new key, and rely on the Web of Trust connecting the new key to the Master Signing Keys: https://www.archlinux.org/master-keys/
Usually, no user intervention is necessary, unless your GnuPG installation is broken and cannot contact the keyservers to do automagic GnuPG things, in which case you still do not need to lsign any key ever.
Marginal trust is nowhere in that relationship, though. Marginal trust implies that the Master Signing Keys are somehow broken, for example one of the five keys is *corrupt* and any Developer or Trusted User with only three signatures, one of which is from the corrupted key, would not be marked as trusted.
I do not know how they would be corrupted. I know at least one case in the forums, was caused by the user accidentally generating a pacman@localhost key which was set in the future due to a badly set hardware clock during the initial Arch Linux installation process.
I guess I am the only recently added TU whose key is not signed by at least three non-broken master keys in your local keyring. It doesn't matter, the solution is still to fix your pacman-key keychain. There have been numerous forum posts, mailing list threads, IRC discussions, Reddit discussions, Twitter discussions, and for all I know Linux User Group conventions discussing the issue ad nauseam -- and by this I mean to say that this raft of discussion across all forms of social media, happens on an individual level for each new Trusted User, every single time. Without fail.
I will never understand why people continually ask the same questions. And then ask why this bizarre thing happens to them and only to them. How could you possibly know it is so bizarre and unique to you, if you didn't first google for the error, or check the forums, or read through arch-general emails in your Inbox/archives? Because if you had, you would have seen at least one such discussion, and we would not be having this discussion.
...
And now escondida is a TU, so we (the Arch Linux community) will go through the "omg who is this key" cycle *again* in a week or two. Fun...
On 02/11/2018 04:48 PM, Eli Schwartz via arch-general wrote:
There have been numerous forum posts, mailing list threads, IRC discussions, Reddit discussions, Twitter discussions, and for all I know Linux User Group conventions discussing the issue ad nauseam -- and by this I mean to say that this raft of discussion across all forms of social media, happens on an individual level for each new Trusted User, every single time. Without fail.
Thank you for not hacking me :)
If there have been social media discussion on it, then I would never see them. I'm 51, not a bird, I don't tweet, etc... When faced with a "this looks like an Arch problem" (or any other distro problem), after 20 years of experience the resounding proper place to address it is to the distros mailing list - to determining if it can be confirmed and a bug is needed, or, for answer, since there will be no other social whatever that knows more about Arch, than Arch.
When things that are supposed to be seamless and take place under the hood without user intervention -- don't, for whatever reason, I like to understand why if I'm going to rely on my system. I have never created any key for the keyring so there is no possibility I match the key with a future date problem.
I'll search again through the forums to see how to completely dump and restore my arch keyring because --init --updatedb --refresh-key don't work. And, no, I'm certainly not going to trust and social media "Hey, try this..." to fix the problem.
I agree with the statements about social media being a poor choice to post Arch questions. Let's face it, social media is only out for itself and isn't exactly the portrait of being social. This is the internet and you don't need a name or identity to use it to your benefit. The BBS, Forum, Wiki and Mailing Lists are fully featured and very much alive. Why not use something that is native to the Operating System that you are running? Facebook does not develop Arch Linux and it isn't a dedicated platform for Arch Linux. Get involved and support the cause that is Arch Linux.
On Sun, 11 Feb 2018 17:46:30 -0600 "David C. Rankin" drankinatty@suddenlinkmail.com wrote:
On 02/11/2018 04:48 PM, Eli Schwartz via arch-general wrote:
There have been numerous forum posts, mailing list threads, IRC discussions, Reddit discussions, Twitter discussions, and for all I know Linux User Group conventions discussing the issue ad nauseam -- and by this I mean to say that this raft of discussion across all forms of social media, happens on an individual level for each new Trusted User, every single time. Without fail.
Thank you for not hacking me :)
If there have been social media discussion on it, then I would never see them. I'm 51, not a bird, I don't tweet, etc... When faced with a "this looks like an Arch problem" (or any other distro problem), after 20 years of experience the resounding proper place to address it is to the distros mailing list - to determining if it can be confirmed and a bug is needed, or, for answer, since there will be no other social whatever that knows more about Arch, than Arch.
When things that are supposed to be seamless and take place under the hood without user intervention -- don't, for whatever reason, I like to understand why if I'm going to rely on my system. I have never created any key for the keyring so there is no possibility I match the key with a future date problem.
I'll search again through the forums to see how to completely dump and restore my arch keyring because --init --updatedb --refresh-key don't work. And, no, I'm certainly not going to trust and social media "Hey, try this..." to fix the problem.
-- David C. Rankin, J.D.,P.E.
On 02/11/2018 06:46 PM, David C. Rankin wrote:
On 02/11/2018 04:48 PM, Eli Schwartz via arch-general wrote:
There have been numerous forum posts, mailing list threads, IRC discussions, Reddit discussions, Twitter discussions, and for all I know Linux User Group conventions discussing the issue ad nauseam -- and by this I mean to say that this raft of discussion across all forms of social media, happens on an individual level for each new Trusted User, every single time. Without fail.
Thank you for not hacking me :)
If there have been social media discussion on it, then I would never see them. I'm 51, not a bird, I don't tweet, etc... When faced with a "this looks like an Arch problem" (or any other distro problem), after 20 years of experience the resounding proper place to address it is to the distros mailing list - to determining if it can be confirmed and a bug is needed, or, for answer, since there will be no other social whatever that knows more about Arch, than Arch.
I sympathize with the idea, and I'm supposedly one of those young adult types that are thought to only exist on twitter :p I know that twitter mentions it because Morten Linderud mentioned this rant in IRC: https://twitter.com/kaihendry/status/920833500135047168 Otherwise I wouldn't know as I have no interest in the site...
But! It's been mentioned on the mailing list and forums.
See for example https://bbs.archlinux.org/viewtopic.php?id=233480 and https://bbs.archlinux.org/viewtopic.php?id=233710
When things that are supposed to be seamless and take place under the hood without user intervention -- don't, for whatever reason, I like to understand why if I'm going to rely on my system. I have never created any key for the keyring so there is no possibility I match the key with a future date problem.
You did though. :p Or rather, the archiso may have seeded it for you...
I'll search again through the forums to see how to completely dump and restore my arch keyring because --init --updatedb --refresh-key don't work. And, no, I'm certainly not going to trust and social media "Hey, try this..." to fix the problem.
--init does nothing if you already have a secret key in your keyring, broken or not. --updatedb --refresh-keys assumes that your keyring is not broken, and updates it with new information. You need to fix a broken keyring though, which is different.
On Sun, 11 Feb 2018 16:22:04 -0600 "David C. Rankin" drankinatty@suddenlinkmail.com wrote:
On 02/11/2018 07:09 AM, Doug Newgard via arch-general wrote:
I refreshed the keylist with pacman-key no help, I finally just tagged TrustAll at the end of the line in packman.conf and it worked fine. There are screwed up signatures there.
The issue is in your local keyring. Check all of the Arch Master Keys, make sure they're all signed by your local master key.
Can someone please explain why this key trust issue happened? In the past 7 years, running 10+ Arch boxes I have never had to adjust the trust on any key within the arch-keyring. Why all of a sudden, and why on only one box, did I have to --lsign-key for the eschwartz93 key? That is why this seemed so bizarre.
It's hard to say why it happened without you actually checking the Arch Master Keys like I mentioned. You should not be signing eschwartz's key, your pacman local master key should sign all of the Arch Master Keys, and with signatures from 3 of those, eschwartz's key becomes trusted. "Marginal trust" tells me that either eschwartz's key didn't have the 3 required signatures or you haven't signed all of the Arch Master Keys somehow.
participants (5)
-
David C. Rankin
-
Doug Newgard
-
Eli Schwartz
-
freq
-
Simon Doppler