Re: ed25519 keys and mentors.d.n
- Date: Mon, 9 Apr 2018 17:11:17 -0600
- From: Daniele Nicolodi <daniele@xxxxxxxxxx>
- Subject: Re: ed25519 keys and mentors.d.n
On 4/9/18 7:45 AM, Ian Jackson wrote:
> (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.
At the same time gpg2 (and modern ssh implementations) can do gpg agent
forwarding, which is straight forward to setup, and I find to be a great
feature to use gpg in virtual machines, containers, remote hosts,
without having to fiddle with my private keys, and potentially to use
gpg tokens remotely (but I don't have one of those, thus I haven't tried
Also, I have a few simple automated processes that use gpg to sign and
encrypt some messages (still using the gpg binary, without the gpgme
library), and the transition from gpg1 to gpg2 has been painless.
Although, I admit, those do not do anything fancy.