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...