On 08/08/14 02:53 AM, Martti Kühne wrote:
On Fri, Aug 8, 2014 at 8:35 AM, Fabien Dubosson <fabien.dubosson@gmail.com> wrote:
[...]
But it has not the same meaning. Maintainer's name gives me the information that I am installing a package that claims to be provided by this maintainer, or uploaded with this maintainer account. GPG signatures will add the certitude that I'm installing the same package as the maintainer wrote in person. I admit this is not happening really often...
Well, I don't see how this idea is supposed to be compatible with what I see as the benefits of the AUR...
I love that I can make changes and proceed doing so in the course of building and installing a PKGBUILD from the AUR. So the PKGBUILDs I usually install aren't cryptographically similar to the package AUR would provide, deeming any cryptographic signing mechanism useless. The official wording of the AUR - unsupported, not to be fully trusted content - leads to the fact that any AUR helper should notify you of this fact every time you use the AUR and offer you editing between any and all of the files involved.
cheers! mar77i
If the sources were signed, those helpers could use the Pacman keyring to avoid unnecessarily prompting for editing when the user already trusts the packager. A warning that the *specific* package is NOT trusted is more likely to lead to users checking it than a warning stating that *all* AUR packages are untrusted. Of course, AUR helpers could also do this with a list of names as Dave suggested but it doesn't assure end-to-end security (the AUR is a pile of PHP and could quite feasibly be hacked) but they won't be able to leverage the existing trust database already populated with developers, trusted users and any third party repository keys trusted by the user.