Arch Linux User Repository

This PKGBUILD verifies the authenticity of the source via PGP signatures which are not part of the Arch Linux keyring. In order to complete the process it is necessary to import the key(s) from the ‘validpgpkeys’ array into the user’s keyring before calling makepkg. There is a helpful article explaining this process by one of Arch Linux's developers located here: http://allanmcrae.com/2015/01/two-pgp-keyrings-for-package-management-in-arch-linux/

Instructions on importing keys from a keyserver and how to automate the retrieval process can be found in the Arch Linux wiki here: https://wiki.archlinux.org/index.php/GnuPG#Use_a_keyserver This article also contains helpful information describing the installation of GnuPG, its configuration and usage.

Execute the following to import keys using gpg:

gpg --recv-keys <KEYID - See 'validpgpkeys' array in PKGBUILD>

The PGP signature check can be skipped by passing --skippgpcheck to makepkg.

Consult the makepkg manual page for a full list of options. [https://www.archlinux.org/pacman/makepkg.8.html]

kossa: You need gcc-multilib when you want to do any kind of cross compiling, including building things like lib32- packages. You will need to enable [Multilib] to install gcc-multilib which will replace gcc. This goes for any gcc frontends you might have: they will be replaced with a multilib version. pacman generally handles the replacement process gracefully. Thankfully gcc-multilib provides gcc and is capable of building either 32 or 64 bit binaries if all other dependencies are met so it will not be necessary to switch back and forth between gcc-multilib and gcc. It is a relatively easy and painless transition.

@WoefulDerelict: Thank you for those extensive explanations, it helped me a lot to understand what's the way to proceed. Really appreciated. @kossa: It is required to install gcc-multilib when building lib32-* packages. You can safely install this dependency even if it asks you to replace gcc with gcc-multilib, but you need to remember that if later you would like to build some non 32 bit package it will ask you to replace gcc-multilib with gcc, which is also fine. @DrDeath: Please read explanation given by WoefulDerelict (which is now pinned) in order to understand how to avoid manual key imports when building packages with makepkg with gpg verification enabled.

Removing {,.asc} from source line and 'SKIP' from sha1sums let the package built just fine. No keys added.

When I make upgrade I get this error : error: target not found: gcc-multilib, shall I install gcc-multilib ?

lisu_ml: That is unfortunately how the process was designed to work. It is necessary to import the key in order to verify the signature on the source file and help ensure its authenticity. It it generally common practice to increase the security features on a package, not remove them. As this package lacks the security implied by the web of trust surrounding binary repo packages having signed sources one can verify is nice. In the ideal situation upstream has their keys and fingerprints available via https for the user to verify outside the PKGBUILD and help establish trust. You can learn more about the process from one of the Arch Linux developers in his blog here: http://allanmcrae.com/2015/01/two-pgp-keyrings-for-package-management-in-arch-linux/ scorici: It is expected that Arch Linux users are capable of consulting the documentation and working out what they need to do in the vast majority of situations where they find themselves confronted with an unfamiliar process or tool. In those rare cases where our users are unable to find their way the community is available to assist them via a number of common and convenient platforms. Arch Linux really isn't a hands off distribution as you are expected to configure and maintain it to suit your needs. It is entirely possible to configure GnuPG to fetch they keys automatically for a hands off build and installation via makepkg; however, you're expected to have read the documentation and configured GPG's behaviour to facilitate this. The Arch Linux principles are clearly expressed in the wiki (https://wiki.archlinux.org/index.php/Arch_Linux) where it should quickly become obvious that this distribution lacks the hand holding present in ready to use desktop spins like Ubuntu. As a courtesy to users in the AUR I habitually pin a comment to packages that support source signature verification with URLs pointing to Allan's blog post on the matter and the GnuPG wiki entry, specifically the section on using the keyserver and configuring it to automatically retrieve keys here: https://wiki.archlinux.org/index.php/GnuPG#Use_a_keyserver As there is minimal risk in doing so while still allowing them to benefit from the added security of signed sources it is perfectly all right for end users who don't want to fuss with GnuPG to enable automatic retrieval of keys. Just as with the --recv-keys command the keys are just imported into the keyring: they aren't trusted nor is it necessary for them to be. I'll usually finish my informative blurb with an abstract example of the gpg command to fetch the keys as a convenient quick reminder of the syntax: gpg --recv-keys <KEYID - See 'validpgpkeys' array in PKGBUILD>

In case you have to use an alternative keyserver... gpg --keyserver pgp.mit.edu --recv-keys F54984BFA16C640F

I agree with lisu_ml, it complicates things. This is the AUR not the official repos. I don't like manual interventions. Another problem to resolve... If lisu_ml didn't showed how to add the gpg key and what key, I would have no clue about it.

@WoefulDerelict: Yes, my bad, sorry about it. But with the source signature verification, how to avoid forcing users to import the key to their keyring? When I first tried to build the package I got the following error: ==> Verifying source file signatures with gpg... libmng-2.0.3.tar.xz ... FAILED (unknown public key F54984BFA16C640F) ==> ERROR: One or more PGP signatures could not be verified! And I needed to add the key manually: $ gpg --recv-keys F54984BFA16C640F In order to build the package.

lisu_ml: Why did you remove the source signature verification and iterate the package release when you adopted this? You've needlessly disabled a security feature and triggered rebuilds for many users of AUR helpers during their next update.