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.
//Peter
_______________________________________________
libssh2-devel https://cool.haxx.se/cgi-bin/mailman/listinfo/libssh2-devel
Received on 2018-05-08