Re: ed25519 keys and mentors.d.n
Martin Steigerwald writes ("Re: ed25519 keys and mentors.d.n"):
> Ian Jackson - 09.04.18, 15:45:
> > 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.
>
> There is some PGP alternative written in Rust (well except for the
> underlying crypto library nettle). I did not research how far
> advanced it is.
>
> https://sequoia-pgp.org/
Interesting. Thanks for the reference.
I couldn't find the licence. I'm sure that's a mistake. If you know
the Sequoia developers please do ask them about this. If you don't,
please say and I will do so myself.
Regards,
Ian.
--
Ian JacksonThese opinions are my own.
If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.
Re: ed25519 keys and mentors.d.n
On Mon, Apr 09, 2018 at 05:01:01PM -0600, Daniele Nicolodi wrote: > > Have a look at [1] to begin with. > > At a first look that code can be updated to use pgpme and do not call > out to a gpg binary. I think so as well, I just haven't had any tuit (and, more importantly, much motivation) to spend time on it. IIRC gpg is used only to do signature checking, that doesn't reaquite the full gpg at all, but isn't the relevant bit named 'gpgv'? But that's not the point, there is code trying to do parse the output of gpg (iirc, the regular output, not the --with-column one), so it's not really a matter of gpgme/gpgv/gpg/gpg-agent stuff. > Just to be sure, is the code supposed to be run with the libraries > in stable? Yes. Please open a bug (or a MR) to further discuss it, debian-devel is very much not the place for it. And maybe hop by #debexpo on oftc. -- regards, Mattia Rizzolo GPG Key: 66AE 2B4A FCCF 3F52 DA18 4D18 4B04 3FCD B944 4540 .''`. more about me: https://mapreri.org : :' : Launchpad user: https://launchpad.net/~mapreri `. `'` Debian QA page: https://qa.debian.org/developer.php?login=mattia `- signature.asc Description: PGP signature
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
it yet).
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.
Cheers,
Dan
Re: ed25519 keys and mentors.d.n
On 4/8/18 5:54 PM, Georg Faerber wrote: > Hi, > > On 18-04-08 17:29:17, Daniele Nicolodi wrote: >> On 08/04/2018 17:10, Mattia Rizzolo wrote: >>> On Sun, Apr 08, 2018 at 04:41:32PM -0600, Daniele Nicolodi wrote: I just tried to upload a package to mentors.debian.net and it got rejected because is is signed with an ed25519 key: gpg: Signature made So 08 Apr 2018 22:00:14 UTC using ? key ID C18A4F7D gpg: Can't check signature: unknown pubkey algorithm 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. >>> >>> Patches welcome, as usual :) >> >> I can look into that. What code needs to be patched? > > Have a look at [1] to begin with. At a first look that code can be updated to use pgpme and do not call out to a gpg binary. I'll give it a try. Just to be sure, is the code supposed to be run with the libraries in stable? Cheers, Dan
Re: ed25519 keys and mentors.d.n
Ian Jackson - 09.04.18, 15:45: > 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. There is some PGP alternative written in Rust (well except for the underlying crypto library nettle). I did not research how far advanced it is. https://sequoia-pgp.org/ -- Martin
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.
Re: ed25519 keys and mentors.d.n
Hi, On 18-04-08 17:29:17, Daniele Nicolodi wrote: > On 08/04/2018 17:10, Mattia Rizzolo wrote: > > On Sun, Apr 08, 2018 at 04:41:32PM -0600, Daniele Nicolodi wrote: > >> I just tried to upload a package to mentors.debian.net and it got > >> rejected because is is signed with an ed25519 key: > >> > >> gpg: Signature made So 08 Apr 2018 22:00:14 UTC using ? key ID C18A4F7D > >> gpg: Can't check signature: unknown pubkey algorithm > >> > >> 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. > > > > Patches welcome, as usual :) > > I can look into that. What code needs to be patched? Have a look at [1] to begin with. Cheers, Georg [1] https://salsa.debian.org/mentors.debian.net-team/debexpo/blob/live/debexpo/lib/gnupg.py signature.asc Description: Digital signature
Re: ed25519 keys and mentors.d.n
On 08/04/2018 17:10, Mattia Rizzolo wrote: > On Sun, Apr 08, 2018 at 04:41:32PM -0600, Daniele Nicolodi wrote: >> I just tried to upload a package to mentors.debian.net and it got >> rejected because is is signed with an ed25519 key: >> >> gpg: Signature made So 08 Apr 2018 22:00:14 UTC using ? key ID C18A4F7D >> gpg: Can't check signature: unknown pubkey algorithm >> >> 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. > > Patches welcome, as usual :) I can look into that. What code needs to be patched? Cheers, Dan
Re: ed25519 keys and mentors.d.n
On Sun, Apr 08, 2018 at 04:41:32PM -0600, Daniele Nicolodi wrote: > I just tried to upload a package to mentors.debian.net and it got > rejected because is is signed with an ed25519 key: > > gpg: Signature made So 08 Apr 2018 22:00:14 UTC using ? key ID C18A4F7D > gpg: Can't check signature: unknown pubkey algorithm > > 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. Patches welcome, as usual :) > Does this limitation apply only to > mentors.d.n or does it apply to the Debian infrastructure in general? Each service it's on his own in Debian. dak works with gpg2, but apparently debvotee uses gpg1, etc etc. -- regards, Mattia Rizzolo GPG Key: 66AE 2B4A FCCF 3F52 DA18 4D18 4B04 3FCD B944 4540 .''`. more about me: https://mapreri.org : :' : Launchpad user: https://launchpad.net/~mapreri `. `'` Debian QA page: https://qa.debian.org/developer.php?login=mattia `- signature.asc Description: PGP signature
ed25519 keys and mentors.d.n
Hello, I just tried to upload a package to mentors.debian.net and it got rejected because is is signed with an ed25519 key: gpg: Signature made So 08 Apr 2018 22:00:14 UTC using ? key ID C18A4F7D gpg: Can't check signature: unknown pubkey algorithm I guess the infrastructure has not been upgraded to GnuPG 2. I know that elliptic curve cryptography is a bit bleeding edge but I thought that GnuPG had support for it for long enough to make it safe to use it in the context of Debian. Does this limitation apply only to mentors.d.n or does it apply to the Debian infrastructure in general? /me generates a new signing subkey... Cheers, Dan
