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.
Let me introduce my thoughts by explaining the context: when I need an application, I start by looking at the official packages. If it is not existing, I continue by looking in AUR, and eventually if there is no corresponding packages there I wrote my own PKGBUILD and share it. I think this is the most common workflow for arch users.
If there is the need to build packages from AUR, preferences differs more between people. Some likes to use AUR-helpers, others try to avoid using unsupported packages, and a last group always build AUR PKGBUILD manually. Official and own-made packages can be used (more-or-less) safely. AUR packages need to be used with precautions, because they come from untrusted users and can be potentially dangerous. Actually this is one of the reason why some people are not using AUR-helpers and prefer to build packages manually.
People that avoid to use unsupported packages are not concerned by this discussion, so I'll skip them. People that are building packages manually are doing so mainly to deeply check packages they install, so they must not be very interested with AUR package signing (or maybe are they?). I will then focus on people (like me) that use an AUR-helper in their workflow.
I always read PKGBUILDs the first time that I want to install one of them in one of my computers (work, home, laptop). When a new version is released, my AUR-helper will ask me to update it, but after the second or third time I see that the package is well-written, I don't want to look every time at the PKGBUILD, patches and *.install files. In some sense, I start to "trust" to the package owner. With AUR-helpers it is easy to skip this part and just build the packages, but there is a drawback: the package owner can change.
The problem with this situation is if the package is orphaned and a new owner start to maintain it, it would not be noticeable. This is where package signing in AUR would be very useful. You give your trust to some users who maintain several good-quality packages. And as long as you build packages signed by those users, you know you are safe to update them without looking at sources. It would also offers some other warranties: no usurpation of maintainer work, no corruption in case of AUR website weakness, etc.
Also the solution can be quite simple: The `*.src.tar.gz` can be signed by the owner and the signature file can be uploaded to AUR, next to the source aurball. Later, both files can be downloaded by the user or the AUR-helper and verified with gpg. The rest of the logic must be implemented in AUR-helpers.
Some other remarks: - It differs from the notion of TU because the goal is not to give a keyring of trust-able people to all users, but only to permit users who want to trust personally some AUR maintainers to do so. - Of course this doesn't prevent corruption of upstream sources nor offers perfect security. But it is better than nothing, and can potentially focus some unnoticed maintainer changes. - I read some times ago that the goal is to move from AUR to git one day. In this case signing the `*.src.tar.gz` would not be possible and a more complex solution will maybe be needed.
Is something like this envisaged? What are your thoughts about this subject?
Regards, ++ Fabien
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
On Fri, Aug 8, 2014 at 10:06 AM, Dave Reisner d@falconindy.com wrote:
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.
Which reminds me of the old bauerbill Xyne wrote, which did precisely that =)
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 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
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.
In the past, what packages provided by AUR needed signing, because after uploading somebody manipulated the packages? AFAIK https for the AUR downloads and checksums for the upstream downloads in the past didn't cause that often serious trouble, IIRC it usually was safe.
Is there such a security mechanism, if we build from ABS?
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 08/08/14 03:43 AM, Ralf Mardorf wrote:
In the past, what packages provided by AUR needed signing, because after uploading somebody manipulated the packages? AFAIK https for the AUR downloads and checksums for the upstream downloads in the past didn't cause that often serious trouble, IIRC it usually was safe.
Is there such a security mechanism, if we build from ABS?
The AUR has had SQL injection vulnerabilities in the past. It has also had a fair number of CSRF / XSS vulnerabilities allowing actions to be taken on behalf of package maintainers.
It's being well maintained now, but it's still written in a language with many easy ways to shoot yourself in the foot. AFAIK (too lazy to check) it also doesn't have a captcha or similar mechanism to defend against someone brute forcing the password of a specific user.
The checksums are just blindly updated when either a new release is done or upstream decides to fiddle with the last release. The ideal is having a signed package (either binary or source) with signatures for the upstream sources and the new makepkg feature allowing the correct fingerprint to be added in the PKGBUILD.
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 Fri, 08 Aug 2014 at 10:02:30, Daniel Micay wrote:
On 08/08/14 03:43 AM, Ralf Mardorf wrote:
In the past, what packages provided by AUR needed signing, because after uploading somebody manipulated the packages? AFAIK https for the AUR downloads and checksums for the upstream downloads in the past didn't cause that often serious trouble, IIRC it usually was safe.
Is there such a security mechanism, if we build from ABS?
The AUR has had SQL injection vulnerabilities in the past. It has also had a fair number of CSRF / XSS vulnerabilities allowing actions to be taken on behalf of package maintainers.
Yes, I do remember fixing one SQL injection vulnerability and a couple of CSRF/XSS vulnerabilities. However, if I recall correctly, all of them were discovered during code reviews and I cannot remember any vulnerability that affected aur.archlinux.org (i.e. was exploited).
It's being well maintained now, but it's still written in a language with many easy ways to shoot yourself in the foot. AFAIK (too lazy to check) it also doesn't have a captcha or similar mechanism to defend against someone brute forcing the password of a specific user.
Assuming that everyone uses good passwords (suppose the set of "good" passwords has 10^14 elements which is a good lower bound), an attacker doing a request every 10ms still has to wait thousands of years on average. It is likely that we detect the increased server load way earlier. Even if we don't, it is unlikely that the owner of the AUR account still cares about his account in a thousand years time.
The checksums are just blindly updated when either a new release is done or upstream decides to fiddle with the last release. The ideal is having a signed package (either binary or source) with signatures for the upstream sources and the new makepkg feature allowing the correct fingerprint to be added in the PKGBUILD.
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. So I think it is kind of pointless to discuss signed source tarballs now...
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
aur-general@lists.archlinux.org