On Thu, Aug 07, 2014 at 09:57:24PM +0200, Fabien Dubosson wrote:

Hi,

I want to start a discussion about AUR packages signing. If this debate already happened, it means that I'm not really good with Google or unfortunate in the keywords I used in my searches: in these cases forgive me and just give me some pointers.

TL;DR I personally "trust" some AUR users who have several good-quality packages, and an optional way to sign AUR packages would permit me to know that I can build and update their packages without worrying too much.

I did read your proposal, but my comment can be framed in the context of your tl;dr: You don't really seem to want GPG signatures, just a whitelist of package maintainers by name. Any AUR helper could implement support for this today, with no changes to the AUR. d

I did read your proposal, but my comment can be framed in the context of your tl;dr:

You had to be motivated, afterwards it looks horribly long ;-)

You don't really seem to want GPG signatures, just a whitelist of package maintainers by name. Any AUR helper could implement support for this today, with no changes to the AUR.

Of course, this is a working solution and can be implemented right away. 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, but in some case like an AUR website weakness, an usurpation of maintainer's identity or the intrusion of a government in "the internet", this will offer more certitude into the packages (like for official ones). I can live with the current situation without problem, but IMHO, offering the possibility to provide GPG signed packages would be a great plus in the future. Regards, ++ Fabien

On 08/08/14 02:53 AM, Martti Kühne wrote:

On Fri, Aug 8, 2014 at 8:35 AM, Fabien Dubosson 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.

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 idea of signing packages sources is not to prevent modifying or installing modified packages nor to verify signatures of built packages. It would only check that the `*.tar.gz` you received from AUR has been signed by the maintainer, thus have not been modified by anyone else in-between. Once the sources are verified, is up to the user to do modifications and build packages. But at least you have the certainty about the original PKGBUILD author and source files content.

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.

Any AUR helper will still notify people that they are using unsupported packages and will do exactly the same building process as now. But users would have the possibility: 1. To verify the author and the content of a package source (if they want and if available). 2. To personally/locally trust a maintainer hence simplifying the package management/updates. (Also see Daniel Micay answer) Regards, ++ Fabien

On Fri, 2014-08-08 at 09:46 +0200, Fabien Dubosson wrote:

It would only check that the `*.tar.gz` you received from AUR has been signed by the maintainer

The tar archives from https://www.kernel.org are signed. Is it really needed for AUR? Btw. I several years build kernels without checking the signing.

On a side note, with the release of AUR 4.0.0, we are no longer going to use source tarballs. Every source package will have its own Git repository and you can use signed tags or signed commits.

Actually that is more than a side note, that answers my main concern. Glad to hear that it would be possible to ensure end-to-end verification in a future AUR version. Just curious, do you have an idea of the planning of 4.0.0 release? (Very roughly: 6 months, 1 year, more?)

So I think it is kind of pointless to discuss signed source tarballs now...

I agree