Release schedule

[George Nachman]

I was very glad to see ECDH key exchange committed! I would like to update
my app to use it, but I'm not comfortable releasing code from master as it
looks like development is quite active. I see that official releases are
infrequent, however. Should I hang tight until the next release? If so, any
guess when that might be?

[Peter Stuge]

Post by George Nachman
I was very glad to see ECDH key exchange committed! I would like to update
my app to use it, but I'm not comfortable releasing code from master as it
looks like development is quite active.

I've gotten back into work around the library lately and I noticed that
the new ECDH kex isn't as separated from unrelated code as it should
be, I would like that to be cleaned up before a release. (A significant
amount of code was needlessly copypasted into all crypto backends,
*replacing* previous abstraction which was still suitable.)

I sent some patches a while back which may or may not be pending still -
sorry, I'm doing other things for one more week but then I'll come back
to the library and try to look at those loose ends, if noone else does
it first.

Development may be active, but I don't know if there are major things
being worked on at the moment? If not, I think a release could be made
even though development is ongoing.


//Peter
_______________________________________________
libssh2-devel https://cool.haxx.se/cgi-bin/mailman/listinfo/l

[Will Cosgrove]

Hi Peter,

Post by Peter Stuge

Post by George Nachman
I was very glad to see ECDH key exchange committed! I would like to update
my app to use it, but I'm not comfortable releasing code from master as it
looks like development is quite active.

I've gotten back into work around the library lately and I noticed that
the new ECDH kex isn't as separated from unrelated code as it should
be, I would like that to be cleaned up before a release. (A significant
amount of code was needlessly copypasted into all crypto backends,
*replacing* previous abstraction which was still suitable.)

Could you be more specific here? The ECDH kex (and related code) is using the OpenSSL backend and is written in a very similar way to the RSA/DSA backends using all the given abstractions. There is nothing significant was copy-pasted into all backends, what are you referring to here? The only thing I can think of is a couple defines. What abstraction was replaced?

Post by Peter Stuge
I sent some patches a while back which may or may not be pending still -
sorry, I'm doing other things for one more week but then I'll come back
to the library and try to look at those loose ends, if noone else does
it first.
Development may be active, but I don't know if there are major things
being worked on at the moment? If not, I think a release could be made
even though development is ongoing.

I have an open PR that includes the OpenSSH key file format support and ED25519 key support which is quite large.

Cheers,
Will
_______________________________________________
libssh2-devel https://cool.haxx.se/cgi-bin

[Peter Stuge]

Post by Will Cosgrove

A significant amount of code was needlessly copypasted into all
crypto backends, *replacing* previous abstraction which was still
suitable.

Could you be more specific here?

I'm sorry: I looked into it now and I confused ECDH with "only" DH.

Post by Will Cosgrove
The ECDH kex (and related code) is using the OpenSSL backend and is
written in a very similar way to the RSA/DSA backends using all the
given abstractions. There is nothing significant was copy-pasted
into all backends, what are you referring to here? The only thing
I can think of is a couple defines. What abstraction was replaced?

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 is so so wrong to push complexity which is common to all but one
backends *from common code **to** backends*. It is the direct opposite
of what we should be doing.

A better solution would be to add a few lines in common code allowing
backends to support either one of DH and modexp at their option.

modexp also ties into RSA, so backends may now have to support RSA
themselves, or individually re-implement RSA using that same modexp
code.

This change made me really upset when I discovered it, and still does. >:(

Post by Will Cosgrove

I sent some patches a while back which may or may not be pending still

An example of the opposite of what I describe above is my AES-CTR patch
in that set. I don't use GitHub so I sent the patches to the list. That
patch implements CTR in common libssh2 code if a backend only supports
AES-CBC.

Post by Will Cosgrove

I don't know if there are major things being worked on at the moment?

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.


//Peter
_______________________________________________
libssh2-devel https://cool.haxx.se/cgi-bin/mail

[Will Cosgrove]

Post by Peter Stuge

Post by Will Cosgrove
What abstraction was replaced?

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.

Post by Peter Stuge

Post by Will Cosgrove

I don't know if there are major things being worked on at the moment?

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. The later would allow other backends to use it for their key support if there is interest and bringing it to them. The former allows us to not worry about keeping it up to date if there ever is modifications.

Will





_______________________________________________
libssh2-devel https://cool.haxx.se

[Peter Stuge]

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.

The issue was when I wrote the ED25519 support, OpenSSL had not yet

I wrote OpenSSH. Consider reusing that code instead.


//Peter
_______________________________________________
libssh2-devel https://cool.haxx.se/c