:::::::::::: The fact that some people don't check the PKGBUILD is irrelevant, since an Arch user given complete responsibility over its system. In contrast, some helpers have clearly a dangerous security flaw.

+

:::::::::::: The fact that some people don't check the PKGBUILD is irrelevant, since an Arch user is given complete responsibility over its system. In contrast, some helpers have clearly a dangerous security flaw.

Revision as of 21:52, 1 June 2013

Authors of each front end should post a short (2-3 line) description of their creation, along with a homepage link and an AUR link (where applicable). A link to a screenshot page would also be nice (if applicable).

Secure column in comparaison table

Description says "tries to protect the user", I don't know what "tries" means but if we take the default behavior of aur helpers marked as secure :

owl remains on cower to download deps so, it doesn't source PKGBUILD but calls makepkg without further questions, so finally, PKGBUILD is sourced.

aura does the same

pbfetch sources PKGBUILD (even if it removes build ())

pacaur sources PKGBUILD (it can be configured to remains on cower)

...

As far as I know, only cower is secure (it builds/installs nothing) and spinach (and pacaur with secure on) ask before calling makepkg.

The only thing secure in dealing with AUR package is knowing what AUR is about.

"Secure" simply means the PKGBUILDs aren't sourced ***before*** the user has a chance to inspect the PKGBUILD himself. Makepkg does source the PKGBUILD obviously, it doesn't mean using it is insecure (but using it blindly is). For example, packer source the PKGBUILD before showing it to the user, unless the --preview option is passed. And so does pacaur (when using the bash solver), although the PKGBUILDs are scanned for potential malicious pseudo code using sudo. Spyhawk 12:07, 15 May 2013 (UTC)

So, just to include also cower in the definition, I think a more correct formulation would be: "Secure means that the application, by default, doesn't source the PKGBUILD at all, or, before doing it, reminds the user and offers him the opportunity to inspect it manually".

Note though that the inspection of a PKGBUILD is always a separate human operation that the user has to do deliberately, and it's independent of the helper being used; this means that every "secure" application can be used insecurely if the user doesn't inspect the PKGBUILD, and vice versa every "insecure" application can be used securely if e.g. the user inspects the PKGBUILD through the AUR website.

Also, the "by default" clause is IMHO very important, in fact you could for example use packer with an alias that runs it with the --preview flag, thus making it a "secure" application, with just such a minimal change.

By the way, I haven't used yaourt for a while, but IIRC it used to let the user review the PKGBUILD after downloading it; it's not clear why it's not considered secure.

In the end, my opinion is that every application offers different degrees of security, and trying to sum all up in a Yes/No column is too simplistic: I would leave more verbose security considerations in the descriptions of every application above the table, or at least I would add some words in the "Specificity" column.

I like your definition, but a shorter one would be welcome (if that is possible?). Of course the security of helper heavily depends on the user, but it is expected to take his full responsibility and check the PKGBUILDs. An "insecure" helper simply has a security flaw, independently of the user.

Yaourt does scan dependencies before letting the user having a look at the PKGBUILDs, so that is similar to what packer does by default. However, yaourt seems to do some other step in between but I haven't been able to understand why and for which purpose (yaourt's code is a bit cryptic to me, Tuxce might better explain what this is fully about here).

I do agree that it is hard to summarize the security aspect with a "Yes/No" box only, and so is the accuracy of the dependencies solver. Security is always done at the expense of the efficiency of the helper, and actually the "fully secure" helper are also the worst in solving dependencies. On the other hand, bash solvers are fully accurate, but are the less secure. Hopefully, this issue will be solved soon and the JSON rpc interface will become much more reliable, so helper could entirely rely on it instead of looking at the downloaded PKGBUILDs.

The definition I've proposed is just my attempt to interpret, in a more coherent way, the idea of "secure" you're using in the table: I don't think it can be made shorter than that, also because IMHO it's too biased as it analyzes only a little part of the problem, thus oversimplifying it.

I still don't get what you exactly mean with An "insecure" helper simply has a security flaw, independently of the user: what is this user-independent security flaw? If it's just the fact that the application doesn't remind the user to check the PKGBUILD manually, personally I wouldn't consider it a security flaw, in fact I think the real security flaw, which is intrinsic to the AUR, is in the fact that the user, even before launching the helper, 1) must be aware that the helper is going to source some third-party code on his machine, and 2) must be able to understand that code in order to decide if it's safe or not; now, every user should be aware of this when installing AUR packages, and the fact that the helper reminds the user or not does really make a minimal difference in terms of security.

I'm not referring to any situation where the user does not check the PKGBUILDs (or check but still continues despite the PKGBUILD being malicious). As previously written above, I'm referring to security flaw that sources the PKGBUILDs ***before*** the user is asked to view the PKGBUILDs himself. So a malicious code would be executed even before the user has a look at the PKGBUILD. Packer (without --preview) is the most stunning example here.

Well, it seems we've fallen into a loop we can't really break: each of us has exposed enough arguments, let's leave this discussion open for a while and see if somebody else supports one or the other side.

Does the secure definition agreed among the developer and user base? Base on the discussion, the answer is no.

I myself do not think the time of sourcing PKGBUILD can be the seperate line between secure and no secure. If source PKGBUILD is danger, then source the PKGBUILD before user checking is 100% danger and after is 95% danger. Most people do not check the PKGBUILD, they just install blindly. Even if they do, few of the could find the danger hiden there.

So my suggestion is remove secure column until the definition is well understood between developer and user community.