[Dev] New packaging standards/policy discussion

fauno fauno at endefensadelsl.org
Sat Aug 1 01:05:54 GMT 2015

Luke <g4jc at openmailbox.org> writes:

> On 07/31/2015 01:24 PM, Michał Masłowski wrote:
>>> 2) Sign stuff manually using SHA512sum and openssl's whirlpool (see my
>>> PKGBUILDs for an example of this fail-safe); and import any GPG
>>> signatures from upstream as needed, adding them to validpgpkeys field
>>> for GPG verification.
>> Fix the tools so no manual work is needed here.
> Upstream bug/patch submitted:
> https://bugs.archlinux.org/task/45859
> It will be as easy as including
> sha512sum()
> whirlpoolsum()
> in the PKGBUILD.

you can add them to makepkg.conf (we can also add them to pacman's
makepkg.conf so it's default)

>>> 3) Sign the PKGBUILD with GPG:
>>> gpg --default-key [YOURKEYID] -b PKGBUILD
>> Another manual step; also puts non-source files in the git repo.
>> No code review is in this procedure.
> I don't see any way around this yet. You could do this in batch if desired.
> parallel gpg --default-key [yourkey] -b ::: PKGBUILD

you can add default-key to gpg.conf so you don't to specify it and it's
also useful if you use throw-keyids when encrypting

> If people are using abs it pulls PKGBUILD and related source files,
> adding a .sig allows abs users to validate the PKGBUILD was created by
> the claimed PKBUILD Maintainer. I consider this better than unsigned
> package builds since it wouldn't take much to alter a PKGBUILD and
> re-push. Then someone would need to go back and trace git commits to
> figure out who. Even then unless the git is signed it'll be very hard to
> determine how that happened since everyone is using the same git user,
> and it would be trivially easy to spoof username in gitconfig should an
> attacker actually gain access.

i'd prefer armored signatures so we don't bloat git's history with
binary blobs.

> Regarding the code review, thankfully gpg is pretty straight forward
> since we can use --verify.

i understood mtjm was refering to other people reviewing the pkgbuild
code before publishing the resulting binary package.  we can do "pair
packaging" but it'll be bothersome and bureaucratic :P

have you thought of a way to verify a binary package was the result of a

> The only unreviewed portion is my two hash skip functions since it is
> not possible to hash-check a file you will be altering. (in this case
> the GPG signature which is created /after/ the PKGBUILD)

i think the debian way is to sign the package description inline?

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 584 bytes
Desc: not available
URL: <https://lists.parabola.nu/pipermail/dev/attachments/20150731/47e732df/attachment.sig>

More information about the Dev mailing list