On Mon, 4 Jan 2016, Peter Stuge wrote:> Hi Kaleb, > > Kaleb Himes wrote: > > OpenSSH port Location: https://github.com/kaleb-himes/openssh-portable.git > > I'm afraid this repository is too messy to be useful. :\ > > You need to use the features offered by git to preserve commit ids if > anyone else besides yourself is going to be able to work with this, > in particular developers who otherwise work with the upstream repo. > > If you are interested in contributing your work to the project then > you have to rebase your changes on top of the current upstream code.There's another problem - I just noticed that WolfSSL is GPL. We have no interest in adding support for a GPL crypto library. -d
(I did not look at the code yet, begging forgiveness:) How well structured is OpenSSH if one would want to use alternative SSL implementation? Or, if I rephrase the question - how married is OpenSSH to OpenSSL? Would it make sense to refactor (if it is not done yet) openssh to use generic API for communicating with any SSL implementation? Or is the general stance on this subject "the new SSL implementation should provide openssl-compatible API to be usable with openssh"? I have no interest in any side of the argument, just curious. b. On 4 January 2016 at 23:15, Damien Miller <djm at mindrot.org> wrote:> On Mon, 4 Jan 2016, Peter Stuge wrote: > > > Hi Kaleb, > > > > Kaleb Himes wrote: > > > OpenSSH port Location: > https://github.com/kaleb-himes/openssh-portable.git > > > > I'm afraid this repository is too messy to be useful. :\ > > > > You need to use the features offered by git to preserve commit ids if > > anyone else besides yourself is going to be able to work with this, > > in particular developers who otherwise work with the upstream repo. > > > > If you are interested in contributing your work to the project then > > you have to rebase your changes on top of the current upstream code. > > There's another problem - I just noticed that WolfSSL is GPL. We have > no interest in adding support for a GPL crypto library. > > -d > _______________________________________________ > openssh-unix-dev mailing list > openssh-unix-dev at mindrot.org > https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev >
(I did not look at the code yet, begging forgiveness:) How well structured is OpenSSH if one would want to use alternative SSL implementation? Or, if I rephrase the question - how married is OpenSSH to OpenSSL? Would it make sense to refactor (if it is not done yet) openssh to use generic API for communicating with any SSL implementation? Or is the general stance on this subject "the new SSL implementation should provide openssl-compatible API to be usable with openssh"? I have no interest in any side of the argument, just curious. b. On 4 January 2016 at 23:15, Damien Miller <djm at mindrot.org> wrote:> On Mon, 4 Jan 2016, Peter Stuge wrote: > > > Hi Kaleb, > > > > Kaleb Himes wrote: > > > OpenSSH port Location: > https://github.com/kaleb-himes/openssh-portable.git > > > > I'm afraid this repository is too messy to be useful. :\ > > > > You need to use the features offered by git to preserve commit ids if > > anyone else besides yourself is going to be able to work with this, > > in particular developers who otherwise work with the upstream repo. > > > > If you are interested in contributing your work to the project then > > you have to rebase your changes on top of the current upstream code. > > There's another problem - I just noticed that WolfSSL is GPL. We have > no interest in adding support for a GPL crypto library. > > -d > _______________________________________________ > openssh-unix-dev mailing list > openssh-unix-dev at mindrot.org > https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev >
Daniel Kahn Gillmor
2016-Jan-05 03:10 UTC
Alternate Open Source Crypto Solution in OpenSSH
On Mon 2016-01-04 20:35:05 -0500, Bostjan Skufca wrote:> Would it make sense to refactor (if it is not done yet) openssh to use > generic API for communicating with any SSL implementation? Or is the > general stance on this subject "the new SSL implementation should provide > openssl-compatible API to be usable with openssh"?OpenSSH doesn't use any of the "SSL" (or TLS) features of OpenSSL. It just uses it for its library of cryptoprimitives. There have been several mentions of possibly swapping out crypto libraries in the past (a few in the last few months iirc), but it is currently not designed with such a platform-independent crypto-primitive API in mind. Damien, you said you're uninterested in linking to a GPL library -- is OpenSSH policy the same for LGPL libraries as well? (i'm thinking of nettle, which is licensed LGPL-2.1+, and has a very nice API for cryptoprimitives) --dkg
On Tue, 5 Jan 2016, Bostjan Skufca wrote:> (I did not look at the code yet, begging forgiveness:) > > How well structured is OpenSSH if one would want to use alternative SSL > implementation? Or, if I rephrase the question - how married is OpenSSH to > OpenSSL? > > Would it make sense to refactor (if it is not done yet) openssh to use > generic API for communicating with any SSL implementation? Or is the > general stance on this subject "the new SSL implementation should provide > openssl-compatible API to be usable with openssh"? > > I have no interest in any side of the argument, just curious.We're happy to factor out the openssl API, and I've started doing so: https://github.com/djmdjm/openssh-openbsd/tree/openssl-wrap This is doing some of the harder parts first: DH and BIGNUM, though the latter only in KEX. I'd like to wrap all BIGNUM use eventually though. Replacing symmetric ciphers and MACs are considerably easier, since most use of them is via cipher.h and digest.h APIs. -d