[aur-general] Discussion about AUR packages signing

[Fabien Dubosson]

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 801 bytes
Desc: not available
URL: <http://mailman.archlinux.org/pipermail/aur-general/attachments/20140807/2cf65f0e/attachment.asc>