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
