Interest in other signature libs/tools?

[Jeremy Huntwork]

On Sun, Dec 26, 2021 at 6:24 PM Bjoern Bidar <bjorn.bidar at thaodan.de> wrote:
>
> Or what are the problems with the existing solution, what should be changed?
> For example if are problems interfacing  with gpgme e.g. compared mininsign?
>

To be very clear, I'll just state again that I'm not proposing that
Arch undertake a change, or that pacman should drop support for gpgme.
My motivation is as a downstream user of pacman, and for my needs, I
would like to use a simpler, and more modern signature solution.

gpgme pulls in a lot of extra libraries and complexity that isn't
required for just package signing. I think you can see the difference
in complexity too by comparing pacman's current code for key
verification with the sample code here:
https://github.com/vstakhov/asignify#libasignify-api Of course a real
world implementation would require a bit more, but I think it still
illustrates the point.

Beyond that, some have made arguments that PGP is just generally bad:
https://latacora.micro.blog/2019/07/16/the-pgp-problem.html But even
without those arguments, the complexity alone makes it less than ideal
for my use cases.

Up to now, the design of my distro has been very light and simple. I
can create a base Docker image with pacman and busybox at about 5MB. I
have been compiling pacman statically, and if I add in gpgme, pacman's
size doubles (IIRC). Besides that, when I last tested, it still
required that the gpg executable itself (and its dependencies) be
present on the machine.

At this point, my plan is to use pacman with asignify. It would just
be much nicer if I didn't need to maintain my own patch/fork.

JH