Subject: Re: Release schedule

Re: Release schedule

From: Peter Stuge <>
Date: Tue, 8 May 2018 09:16:33 +0000

Will Cosgrove wrote:
> > I consider commit f7daf31 to be completely wrong as it stands. The goal
> > is fine, to enable backends to call system DH, but the implementation
> > is particularly backwards.
> It does seem like the common functions could stay in kex.c while
> calling into the specific backends as needed. I’d review a PR or
> diff if you wanted to tackle bringing this back.

Thanks a lot! Yes, I would look at doing that next week.

> >> I have an open PR that includes the OpenSSH key file format support
> >> and ED25519 key support which is quite large.
> >
> > Cool. Is there more work to be done on those, or do they "only" need
> > review? I'll have some libssh2 time the week after next.
> It’s currently at review stage, it is fully functional. Key
> reading is backend agnostic. However, it is only implemented in
> OpenSSL. ED25519 is also only in OpenSSL. It is just a matter of
> if we wait for OpenSSL 1.1.1 to ship and use ED25519 support from
> there, or use the curve implementation from BoringSSL which is part
> of the PR.

I'm certainly in favor of backend-agnostic code.

But do I remember correctly that BoringSSL is derived from OpenSSL?

In that case I think it would be nicer to reuse the ed25519 code in
OpenSSH instead, to not force the compliance requirements set out by
the OpenSSL license onto libssh2 users with a different backend.

Received on 2018-05-08