OpenSSL 3.0
wiki.openssl.org
OpenSSL 3.0
1–10 of 106 posts
Re: OpenSSL 3.0
#2One of the major improvements here: this finalizes the license change to Apache 2.0, which makes OpenSSL finally GPL-compatible. That removes one of the major reasons people had to avoid it.
(Specifically, OpenSSL is now compatible with anything licensed "GPLv3", "GPLv3 or later", or "GPLv2 or later". It's not compatible with "GPLv2 only", but that's a relatively small amount of software.)
Other major improvements: TLS1.3 support, Linux kernel TLS support (hand off crypto to the kernel and then read/write as though you had a normal file descriptor and let the kernel handle the crypto), and opaque low-level structures (no more dependencies on OpenSSL internals).
Re: OpenSSL 3.0
#3One of the major improvements here: this finalizes the license change to Apache 2.0, which makes OpenSSL finally GPL-compatible. That removes one of the major reasons people had to avoid it. (Specifically, OpenSSL is now compatible with anything licensed "GPLv3", "GPLv3 or later", or "GPLv2 or later". It's not compatible with "GPLv2 only", but that's a relatively small amount of software.) Other major improvements: T…
Isn't the Linux kernel "GPLv2 only"?
Re: OpenSSL 3.0
#4One of the major improvements here: this finalizes the license change to Apache 2.0, which makes OpenSSL finally GPL-compatible. That removes one of the major reasons people had to avoid it. (Specifically, OpenSSL is now compatible with anything licensed "GPLv3", "GPLv3 or later", or "GPLv2 or later". It's not compatible with "GPLv2 only", but that's a relatively small amount of software.) Other major improvements: T…
Isn't the Linux kernel "GPLv2 only"?
Yes, but it's unlikely to link in a userspace library. This does prevent adapting code from OpenSSL to put in the kernel, but there are plenty of other sources to adapt code from.
There are a few other notable codebases that are GPLv2-only, but most projects using the GPL use either "v2 or later" or "v3 or later".
Re: OpenSSL 3.0
#5I worry that this is going to break so many programs and scripts in the same way that the switch from Linux 2.6 did..
Re: OpenSSL 3.0
#6Obvious question that it don't see answered on the page: why not 2.0?
Re: OpenSSL 3.0
#7I worry that this is going to break so many programs and scripts in the same way that the switch from Linux 2.6 did..
That already happened once with OpenSSL 1.1 which also wasn’t really backwards compatible.
It was messy then, it will be messy now, though when you took the 1.1 opportunity to modernize your code to current best-practice as requested by the library rather than just fixing the minimum, you might be pretty ok this time around
Re: OpenSSL 3.0
#8I worry that this is going to break so many programs and scripts in the same way that the switch from Linux 2.6 did..
That already happened once with OpenSSL 1.1 which also wasn’t really backwards compatible. It was messy then, it will be messy now, though when you took the 1.1 opportunity to modernize your code to current best-practice as requested by the library rather than just fixing the minimum, you might be pretty ok this time around
You know, I think it was a deep memory of the switch off of 0.9.8 that gave me the initial thought without realizing. Maybe the older programs will be more prepared after all. Although I hope they weren't expecting a single-digit increment..
Re: OpenSSL 3.0
#9Obvious question that it don't see answered on the page: why not 2.0?
https://www.openssl.org/blog/blog/2018/11/28/version/
They want to use the same version numbers for OpenSSL and a FIPS module, and the FIPS module was already versioned at 2.X.X.
Re: OpenSSL 3.0
#10> OpenSSL versions with the same major number are API and ABI compatible
Finally!
> A proper HTTP(S) client in libcrypto supporting GET and POST, redirection, plain and ASN.1-encoded contents, proxies, and timeouts
Is this really necessary? If you want a 'real' http client, you're probably using libcurl anyway (which is permissively licensed, more stable, and supports http/3).