Re: [aur-general] Discussion about AUR packages signing
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. signature.asc Description: OpenPGP digital signature
Re: [aur-general] Discussion about AUR packages signing
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?
Re: [aur-general] Discussion about AUR packages signing
> 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 pgpaK_68p7QWC.pgp Description: PGP signature
Re: [aur-general] Discussion about AUR packages signing
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. signature.asc Description: OpenPGP digital signature
Re: [aur-general] [Bulk] Re: Discussion about AUR packages signing
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.
[aur-general] Signoff report for [community-testing]
=== Signoff report for [community-testing] === https://www.archlinux.org/packages/signoffs/ There are currently: * 2 new packages in last 24 hours * 0 known bad packages * 0 packages not accepting signoffs * 0 fully signed off packages * 16 packages missing signoffs * 0 packages older than 14 days (Note: the word 'package' as used here refers to packages as grouped by pkgbase, architecture, and repository; e.g., one PKGBUILD produces one package per architecture, even if it is a split package.) == New packages in [community-testing] in last 24 hours (2 total) == * libgit2-1:0.21.1-1 (i686) * libgit2-1:0.21.1-1 (x86_64) == Incomplete signoffs for [community] (16 total) == * acpi_call-1.1.0-11 (i686) 0/1 signoffs * bbswitch-0.8-15 (i686) 0/1 signoffs * libgit2-1:0.21.1-1 (i686) 0/1 signoffs * r8168-8.038.00-10 (i686) 0/1 signoffs * rt3562sta-2.4.1.1_r1-9 (i686) 0/1 signoffs * tp_smapi-0.41-52 (i686) 0/1 signoffs * vhba-module-20140629-6 (i686) 0/1 signoffs * virtualbox-modules-4.3.14-5 (i686) 0/1 signoffs * acpi_call-1.1.0-11 (x86_64) 0/2 signoffs * bbswitch-0.8-15 (x86_64) 0/2 signoffs * libgit2-1:0.21.1-1 (x86_64) 0/2 signoffs * r8168-8.038.00-10 (x86_64) 0/2 signoffs * rt3562sta-2.4.1.1_r1-9 (x86_64) 0/2 signoffs * tp_smapi-0.41-52 (x86_64) 0/2 signoffs * vhba-module-20140629-6 (x86_64) 0/2 signoffs * virtualbox-modules-4.3.14-5 (x86_64) 0/2 signoffs == Top five in signoffs in last 24 hours == 1. fyan - 6 signoffs 2. foutrelis - 4 signoffs 3. eric - 4 signoffs 4. ronald - 2 signoffs
[aur-general] Delete Request
The maintainer switched to GIT only so i renamed the package. Please delete: https://aur.archlinux.org/packages/kdestyle-kvantum-kde4/ Thanks, Andy
Re: [aur-general] Delete Request
On 08/08, sxe wrote: The maintainer switched to GIT only so i renamed the package. Please delete: https://aur.archlinux.org/packages/kdestyle-kvantum-kde4/ Requests are sent from the AUR web interface now. Log into the AUR, go to the package's page and click 'File request' in the action box to the right. -- Sincerely, Johannes Löthberg PGP Key ID: 3A9D0BB5 pgp3rqChmcd2G.pgp Description: PGP signature
Re: [aur-general] Discussion about AUR packages 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...
