Current status of --enable-crypto
Daniel Franke
dfoxfranke at gmail.com
Fri Jan 27 18:37:07 UTC 2017
On 1/27/17, Mark Atwood <fallenpegasus at gmail.com> wrote:
> If we are going to have an SSL dependency, I have a pretty strong
> preference towards WolfSSL
WolfSSL is full GPLv2 with no or-any-lrater-version provision. Are you
comfortable with having a dependency licensed under those terms?
Possibly more importantly, WolfSSL doesn't support everything that I'm
going to need in order to implement NTS: no ALPN, and no RFC5705 key
export.
> if we are going to have an OpenSSL dependency, it needs to be to the latest
> stable OpenSSL release.
Of course.
> What would be using an SSL library for, that libsodium does not already
> provide?
Currently, just the MD5 and SHA-1 primitives. NTS will need a full TLS
stack somewhere, although I intend for it to live in a separate
process.
> What all are we using libsodium right now for?
Just random number generation. When we had a discussion about this a
year ago, the consensus was that the right thing to do was to pull out
the (tiny) relevant bits of libsodium for this and put them into the
tree, because:
1. This was the best way to keep binary size down and avoid an
external dependency.
2. OpenSSL's RAND_bytes() implementation is notoriously
overcomplicated and makes a lot of people (including me) nervous.
#1 is still the case but I'm not sure how much we still care since
RTEMS work seems to have gone by the wayside for now, and we've since
switched to linking against an external libsodium anyhow. #2 is also
still the case but may not be for much longer: OpenSSL devs say that
improving this code is going to be a near-term priority.
More information about the devel
mailing list