Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

OpenSSL 3.0

wiki.openssl.org

Post reply on HN
Print view View original

21–30 of 106 posts

Re: OpenSSL 3.0

#21

Post by scottlamb »

JoshTriplett wrote: post #2

One 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…

Does anyone know if OpenSSL-derived projects like BoringSSL and ring will follow suit in switching to Apache 2.0? And if so, have a guess at how long that will take?

Re: OpenSSL 3.0

#22

Post by jabl »

NiekvdMaas wrote: post #14
JoshTriplett wrote: post #2

One 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…

What does the license change mean for LibreSSL (OpenSSL fork) and GnuTLS which have "a better license" as their main selling point?

The openbsd people behind libressl hate the apache 2.0 license, so they won't be able to copy such code from the openssl project any longer. I'm sure they're happy they have a TLS library with a license they like (new contributions are licensed under the openbsd license) and they can continue developing.

As for gnutls, apache 2.0 license is still incompatible with (L)GPL 2.x, so projects under those licenses without the "or later" clause can't use openssl 3.x->. And of course, the gnutls and openssl API's are different, users can't just link against one or the other without code changes.

Re: OpenSSL 3.0

#23

Post by jabl »

throwaway2048 wrote: post #18
NiekvdMaas wrote: post #14

Earlier quoted context omitted.

What does the license change mean for LibreSSL (OpenSSL fork) and GnuTLS which have "a better license" as their main selling point?

libressl does not have a different license

My understanding is that new libressl code is under the openbsd license, though the original terms still apply as long as they have code under those terms left.

Re: OpenSSL 3.0

#24

Post by tpolzer »

JoshTriplett wrote: post #2

One 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…

Doesn't "GPLv2 or later" specifically allow you to fork into "GPLv2 only"? How can a license be incompatible with only the latter then?

Re: OpenSSL 3.0

#25

Post by saagarjha »

hyperman1 wrote: post #19

Reading chapter 3, upgrading from 1.1.1, it seems strange for a security library to promote ignoring and even suppresing warnings. The best option, upgrading, is mentioned last. I would prefer my security libraries to scream bloody murder if I am using them in a deprecated way.

“Deprecated” need not mean “insecure”.

Re: OpenSSL 3.0

#26

Post by shoo »

terrywang wrote: post #17
JoshTriplett wrote: post #2

One 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…

- Linux Kernel TLS support Is this referring to kernel TLS offload (using linux kernel's TLS connection ooffload infrastrucuture)?

i am unfamiliar with kernel TLS offload [1], but superficially, it looks like that may be supported:

https://github.com/openssl/openssl/blob/43a70f02022ebbc29aa7...

`SOL_TLS` referenced here

https://github.com/openssl/openssl/blob/f059e4cc435b7b850cfc...

as defined here:

https://github.com/torvalds/linux/commit/3c4d7559159bfe1e3b9...

[1] https://www.kernel.org/doc/html/latest/networking/tls-offloa...

Re: OpenSSL 3.0

#27

Post by hyperman1 »

saagarjha wrote: post #25
hyperman1 wrote: post #19

Reading chapter 3, upgrading from 1.1.1, it seems strange for a security library to promote ignoring and even suppresing warnings. The best option, upgrading, is mentioned last. I would prefer my security libraries to scream bloody murder if I am using them in a deprecated way.

“Deprecated” need not mean “insecure”.

Are you willing to take the risk? Deprecated might mean: There are known weaknesses. Or: Less reviewed code path.

Re: OpenSSL 3.0

#28

Post by CrLf »

tpolzer wrote: post #24
JoshTriplett wrote: post #2

One 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…

Doesn't "GPLv2 or later" specifically allow you to fork into "GPLv2 only"? How can a license be incompatible with only the latter then?

IANAL, but “GPLv2 or later” allows you (the recipient of the license) to choose either GPLv2 or GPLv3 (i.e. the one that’s more convenient to you) but does not allow you to prevent others (the recipients of your modified version) from having the same choice.

This goes both ways, “GPLv2 or later” cannot be changed to either GPLv2 or GPLv3 only without permission from everybody that has ever contributed to the codebase.

The FSF requires copyright attribution from cotributors, that’s why they were able to switch their projects to GPLv3-only.

Re: OpenSSL 3.0

#29

Post by hannob »

moonchild wrote: post #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).

Up until now OCSP checks were basically broken in openssl for all OCSP servers which speak only HTTP/1.1 (which is most of them) and only worked with a crude hack where you add an extra HTTP header via command line.

Not sure if this fixes it, but if you include functionality that relies on HTTP then you better support HTTP.

Re: OpenSSL 3.0

#30

Post by dtech »

jabl wrote: post #22
NiekvdMaas wrote: post #14

Earlier quoted context omitted.

What does the license change mean for LibreSSL (OpenSSL fork) and GnuTLS which have "a better license" as their main selling point?

The openbsd people behind libressl hate the apache 2.0 license, so they won't be able to copy such code from the openssl project any longer. I'm sure they're happy they have a TLS library with a license they like (new contributions are licensed under the openbsd license) and they can continue developing. As for gnutls, apache 2.0 license is still incompatible with (L)GPL 2.x, so projects under those licenses without…

Why do they hate APL?
Post reply on HN