On Sun, Dec 26, 2021 at 6:24 PM Bjoern Bidar <bjorn.bidar@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