Re: Is including GPG keys in an AUR package for verifying sources a good
idea? – Hello,
Good reasoning and decision regarding not removing signatures checking.
As for attaching keys, my opinion on that is: you may. My thinking here
is as follows.
Signatures establish a secure channel between the software authors and
the builder/user. If one puts complete trust in a random AUR account,
we can just use SHA512 and stop with the security theater. The user is
expected to acquire and verify the key through a separate route: either
directly from the authors or by using enough witnesses to build trust.
Unavoidably that brings the question: where the user is supposed to
get the key at? Keyservers should be the answer, but have fun playing
hide-and-seek to tell, which server to use. Keys being published whenever
possible is a good option then. That would include AUR.
That leaves one question open: where? I believe the proper place is
the git repository, alongside the PKGBUILD. Keys aren’t expected to
change often, so updates wouldn’t be frequent.
There is little risk in an AUR account offering a malicious key. Public
keys are not expected to be distributed through secure means. Only the
key ID (or the entire fingerprint) has to be confirmed. After all this
is how keyservers work and they are even less trusted than AUR.
What if the victim doesn’t verify the key ID? The worst a malicious
actor could do is publishing an AUR entry with both fake key and its corresponding
key ID. But this gives them power to convey malicious source, what one
can do by simply not offering signatures. There is a minor threat of the
key ending up in their keyring, which can be later used to e.g. send encrypted
email the attacker can read (tamper-evident on recipient’s end: they
can’t decrypt it). But the same can be done with a keyserver.
Cheers
A malicious
