Re: ed25519 keys and mentors.d.n
(dropping -mentors)
Mattia Rizzolo writes ("Re: ed25519 keys and mentors.d.n"):
> On Sun, Apr 08, 2018 at 04:41:32PM -0600, Daniele Nicolodi wrote:
> > I guess the infrastructure has not been upgraded to GnuPG 2.
>
> Yes, when we upgraded the host 1,5 months ago we tried also moving to
> gpg2, but that wasn't as straightforward as we'd hoped…
> So, we've installed gnupg1 and changed the binary used.
Unfortunately, moving from gpg1 to gpg2 is, in general, hard.
gpg2 has a much more complicated architecture, with pet daemons, et
al, which makes serious complications for calling programs. This new
more complicated architecture is also plagued with bugs, including
races. Furthermore, upstream's handling of those bugs has left
something to be desired.
My own experiences:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=868550
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=867783
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=841143
For a wider perspective look in
https://bugs.debian.org/cgi-bin/pkgreport.cgi?src=gnupg2
for bugs mentioning `agent'.
It would be really nice if there were a reliable, maintained, Free,
OpenPGP implementation. Having looked at the code in gnupg2 I doubt
it can ever be made reliable - at least, without either an
unreasonable amount of effort, or major architectural change.
I would be quite happy to rewrite all of my call sites to use a
different program or a different library or whatever. Unfortunately
the one project I'm aware of that sets out to compete with gnupg2
(https://neopg.io/) doesn't look like it will provide what is needed -
but I live in hope.
Ian.
Reply to: