[arch-general] Corrupt Package (confirmed 2 servers) dovecot, jansson, python2-pillow

[Eli Schwartz]

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 at 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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <https://lists.archlinux.org/pipermail/arch-general/attachments/20180211/8cb5200d/attachment.asc>