Discussion:
Corrupt Package (confirmed 2 servers) dovecot, jansson, python2-pillow
(too old to reply)
David C. Rankin
2018-02-11 10:21:00 UTC
Permalink
Raw Message
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 <***@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 <***@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 <***@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.
--
David C. Rankin, J.D.,P.E.
Simon Doppler
2018-02-11 10:42:07 UTC
Permalink
Raw Message
Hi David,

I just tried to download the dovecot package and go no errors (from [1])
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
David C. Rankin
2018-02-11 12:33:56 UTC
Permalink
Raw Message
Post by Simon Doppler
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/
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.
--
David C. Rankin, J.D.,P.E.
Doug Newgard via arch-general
2018-02-11 13:09:34 UTC
Permalink
Raw Message
On Sun, 11 Feb 2018 06:33:56 -0600
Post by David C. Rankin
Post by Simon Doppler
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/
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.
David C. Rankin
2018-02-11 22:22:04 UTC
Permalink
Raw Message
Post by Doug Newgard via arch-general
Post by David C. Rankin
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.
--
David C. Rankin, J.D.,P.E.
Eli Schwartz via arch-general
2018-02-11 22:48:58 UTC
Permalink
Raw Message
Post by David C. Rankin
Post by Doug Newgard via arch-general
Post by David C. Rankin
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...
Post by David C. Rankin
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
***@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...
--
Eli Schwartz
Bug Wrangler and Trusted User
David C. Rankin
2018-02-11 23:46:30 UTC
Permalink
Raw Message
Post by Eli Schwartz via arch-general
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.
freq via arch-general
2018-02-11 23:58:07 UTC
Permalink
Raw Message
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
Post by David C. Rankin
Post by Eli Schwartz via arch-general
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.
--
freq <***@lavabit.com>
Eli Schwartz via arch-general
2018-02-12 00:02:30 UTC
Permalink
Raw Message
Post by David C. Rankin
Post by Eli Schwartz via arch-general
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
Post by David C. Rankin
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...
Post by David C. Rankin
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.
--
Eli Schwartz
Bug Wrangler and Trusted User
Doug Newgard via arch-general
2018-02-12 00:05:41 UTC
Permalink
Raw Message
On Sun, 11 Feb 2018 16:22:04 -0600
Post by David C. Rankin
Post by Doug Newgard via arch-general
Post by David C. Rankin
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.

Loading...