7 ms·

OpenSSL 3.0

150 points by yabones 5y ago

thristian 5y ago
For anyone else confused by the sudden version number bump, which isn't obviously explained in the linked changelog: - OpenSSL is switching to (basically) SemVer, where the major version indicates API/ABI compatibility - 2.x version numbers were already used by the OpenSSL FIPS library, so by bumping everything to 3.x the OpenSSL and OpenSSL FIPS version numbers will be in sync Source: https://www.openssl.org/blog/blog/2018/11/28/version/ https://www.openssl.org/blog/blog/2018/11/28/version/
Phurist 5y ago
Oh no... more software that will break.
- cpach 5y ago
  Get a job in tech, they said. It’ll be fun, they said.
  - adolph 5y ago
    For the plumber, a stuck toilet smells like money.
    - cpach 5y ago
      True words!
  - dralley 5y ago
    I'm sure it's more fun than filling potholes...
    - cpach 5y ago
      Depends on who you ask, but personally I agree vehemently.
  - diftraku 5y ago
    At least it's not DNS... right?
    - acheron 5y ago
      DNS isn’t that hard. It’s just a mix of cache invalidation and naming things.
invokestatic 5y ago
Good. The mix and match of 1s, 0s, and letters in the previous versioning system was very hard to track.
- simmo9000 5y ago
  I think there was a 2 and also a 9 as well... From https://www.openssl.org/news/cl30.txt https://www.openssl.org/news/cl30.txt OpenSSL Releases ---------------- - [OpenSSL 3.1](#openssl-31) - [OpenSSL 3.0](#openssl-30) - [OpenSSL 1.1.1](#openssl-111) - [OpenSSL 1.1.0](#openssl-110) - [OpenSSL 1.0.2](#openssl-102) - [OpenSSL 1.0.1](#openssl-101) - [OpenSSL 1.0.0](#openssl-100) - [OpenSSL 0.9.x](#openssl-09x) End from https://www.openssl.org/news/cl30.txt https://www.openssl.org/news/cl30.txt
MichaelMoser123 5y ago
Are there projects/organizations that are switching from openssl to these rust based projects? rustls - https://github.com/rustls/rustls https://github.com/rustls/rustls ring - https://github.com/briansmith/ring https://github.com/briansmith/ring If yes, then what is their experience?
- cjg 5y ago
  Yes - used rustls on a new project rather than the openssl wrapper which we used before. The experience has been pretty good. The problems of shared library version inconsistency have gone. No noticeable downsides.
  - ris 5y ago
    > The problems of shared library version inconsistency have gone. No noticeable downsides. Sure, as long as you commit to releasing an updated version if a vulnerability is ever found in your version of rustls. Edit: oh, and in such a case you should probably release your own CVE too, else not everyone will get the nudge to update.
    - DasIch 5y ago
      OpenSSL is not great about compatibility. If you link to it dynamically, there is a good chance users have to recompile when it is updated which in practice means they'll need to update. This theoretical advantage of shared libraries also doesn't materialize, if containers are used.
      - ris 5y ago
        I do sympathize as I spend a lot of my time maintaining distro packages. But I also fear that in this new world of golang and rust projects with statically linked libraries, few people take their reporting responsibilities seriously. Hell, if they did, a serious vulnerability in a commonly used library would result in an avalanche of CVEs.
    - cjg 5y ago
jabl 5y ago
Apart from API/ABI changes, notable changes are: * Changed the license to the Apache License v2.0. * Switch to a new version scheme using three numbers MAJOR.MINOR.PATCH. - Major releases (indicated by incrementing the MAJOR release number) may introduce incompatible API/ABI changes. - Minor releases (indicated by incrementing the MINOR release number) may introduce new features but retain API/ABI compatibility. - Patch releases (indicated by incrementing the PATCH number) are intended for bug fixes and other improvements of existing features only (like improving performance or adding documentation) and retain API/ABI compatibility. See also the project's blog post about the new release: https://www.openssl.org/blog/blog/2021/09/07/OpenSSL3.Final/ https://www.openssl.org/blog/blog/2021/09/07/OpenSSL3.Final/
- dariusj18 5y ago
  Something I've never quite understood about semantic versioning. Sometimes fixing a bug is a breaking change, especially if someone is relying on that behavior to be bugged. How does one make the distinction?
  - edoceo 5y ago
    > breaking change Seems like Major increment to me. But! If the fix is breaking some previous undefined behaviour to work correct then I think Minor with relnote. But! If the code is not in wide use, bump Patch and move on.
  - dsr_ 5y ago
    If you can't re-link with the new library, it's no longer ABI compatible and thus it's a major version change. If you can re-link with the new library but something no longer works, you need to emit lots of very loud warnings when code calls that function.
  - dahfizz 5y ago
    I think this is why they specifically call out ABI changes. A major release is one that changes the ABI/API - i.e. the C function definitions have changed and you are forced to recompile. A bugfix that breaks someone's workflow but does not change the ABI is not a major release.
orra 5y ago
This is the first version without the obnoxious advertising clause in the licence. Now it's Apache v2. It's a shame that OpenBSD and hence LibreSSL don't like the Apache v2 licence. Now, I think (IMHO) that's mainly OpenBSD being silly. But maybe OpenSSL should dual license under MIT OR Apache, just like Rust.
- hylaride 5y ago
  What's wrong with the BSD license? It's essentially as permissible as it gets...
  - orra 5y ago
    There’s nothing horribly wrong with BSD licenses if you’re wanting something permissive. But there are some minor drawbacks: * there isn’t a "the" BSD licence, but a family of similar licences * MIT is similar in spirit to BSD licences, but has the advantage of being more explicit[1], for example regarding sublicensing. https://opensource.stackexchange.com/questions/217/what-are-the-essential-differences-between-the-bsd-and-mit-licences https://opensource.stackexchange.com/questions/217/what-are-... Finally, as a user, I prefer Apache over MIT because Apache makes patent rights explicit. [1] Being explicit isn't entirely academic. Cf. the historical stooshie about Pine https://en.m.wikipedia.org/wiki/Pine_(email_client)#Licensing_and_clones https://en.m.wikipedia.org/wiki/Pine_(email_client)#Licensin...
    - rdpintqogeogsaa 5y ago
      > Finally, as a user, I prefer Apache over MIT because Apache makes patent rights explicit. The thing is that you cannot really compare MIT and Apache-2.0 directly because they differ in several ways. It's not just MIT+patent clause. Disclaimer: I am not a lawyer. This is not legal advice. Consult an attorney with experience in copyright law wrt software for legal advice. Some ways they differ: 1. The MIT license does not mention patents. Apache-2.0 is explicit about patents and has active defenses (patent litigation against the one granting the license leads to immediate termination of the granted patent rights). 2. You must ship the entire license in both cases, but the mode differs. The MIT license makes you include the copyright notice and permission notice. The Apache-2.0 license makes you ship the Apache-2.0 license text in any case; this does not include attribution in and of itself, which it only mandates for redistribution in source form. 3. If you modify Apache-2.0 software, you must make modified files carry "prominent notices" thating that you changed the files (in practice, this raises interesting questions regarding workflows centered around pull requests because PRs necessarily violate the license until merged). 4. MIT license only requires you to carry around the copyright notice and the license (unless the copyright notice refers to an external file, which you must then keep under the same filename because keeping the copyright notice intact is required; fiat-crypto is one of these incredibly creative projects that does this). Apache-2.0 requires you to always also ship a file if it is a "'NOTICE' text file", assuming this means a text file called "NOTICE", you have to ship an extra file, to which you may add your own copyright notices therein. 5. No implied trademark rights on Apache-2.0. The MIT license does not make any effort to talk about trademarks (thus implied trademark licenses, like with implied patent licenses, might be possible); Apache-2.0 does not grant any trademark rights except for the NOTICE file. If you want something closer to MIT+patent clause, try the Blue Oak Model License.
teddyh 5y ago
Still no support for RFC 7250 (Raw Public Keys).
pjmlp 5y ago
A couple of double frees and memory corruption fixes, oh well.
conradev 5y ago
There are a lot of little tidbits in the changelog. For example: “Interactive mode from the openssl program has been removed From now on, running it without arguments is equivalent to openssl help.” https://github.com/openssl/openssl/blob/master/doc/man7/migration_guide.pod#interactive-mode-from-the-openssl-program-has-been-removed https://github.com/openssl/openssl/blob/master/doc/man7/migr...
hs86 5y ago
For their next release, they should rename the project into OpenTLS and go back to version 1.0. I think the advantages (it's funny) would heavily outweigh the disadvantages (everyone would hate them).
- dveeden2 5y ago
  It was called OpenTLS in the past. https://www.openssl.org/blog/blog/2018/12/20/20years/ https://www.openssl.org/blog/blog/2018/12/20/20years/ Would still be good to rename, but now there are other projects that use that name. Then some way to resolve the name collision is needed.
Maven911 5y ago
I wonder if and when this will be FIPS 140-2 compliant
- posixplz 5y ago
  I assume you mean "validated" and not "compliant" -- the distinction is important. Yes, it will be 140-2 validated. It's being submitted for testing before end of month to make the 140-2 cutoff. (September is the last month for 140-2 submissions. After September, all new FIPS submissions must be for 140-3 validation.) It's fair to assume it will take about 12-18 months from submission to certificate issuance.
wbl 5y ago
And they still haven't fixed the X509 support or the macros behind it. Run away.

150 points by yabones 5y ago

For anyone else confused by the sudden version number bump, which isn't obviously explained in the linked changelog: - OpenSSL is switching to (basically) SemVer, where the major version indicates API/ABI compatibility - 2.x version numbers were already used by the OpenSSL FIPS library, so by bumping everything to 3.x the OpenSSL and OpenSSL FIPS version numbers will be in sync Source: https://www.openssl.org/blog/blog/2018/11/28/version/ https://www.openssl.org/blog/blog/2018/11/28/version/

Phurist 5y ago

Oh no... more software that will break.

cpach 5y ago
Get a job in tech, they said. It’ll be fun, they said.
- adolph 5y ago
  For the plumber, a stuck toilet smells like money.
  - cpach 5y ago
    True words!
- dralley 5y ago
  I'm sure it's more fun than filling potholes...
  - cpach 5y ago
    Depends on who you ask, but personally I agree vehemently.
- diftraku 5y ago
  At least it's not DNS... right?
  - acheron 5y ago
    DNS isn’t that hard. It’s just a mix of cache invalidation and naming things.

invokestatic 5y ago

Good. The mix and match of 1s, 0s, and letters in the previous versioning system was very hard to track.

simmo9000 5y ago
I think there was a 2 and also a 9 as well... From https://www.openssl.org/news/cl30.txt https://www.openssl.org/news/cl30.txt OpenSSL Releases ---------------- - [OpenSSL 3.1](#openssl-31) - [OpenSSL 3.0](#openssl-30) - [OpenSSL 1.1.1](#openssl-111) - [OpenSSL 1.1.0](#openssl-110) - [OpenSSL 1.0.2](#openssl-102) - [OpenSSL 1.0.1](#openssl-101) - [OpenSSL 1.0.0](#openssl-100) - [OpenSSL 0.9.x](#openssl-09x) End from https://www.openssl.org/news/cl30.txt https://www.openssl.org/news/cl30.txt

MichaelMoser123 5y ago

Are there projects/organizations that are switching from openssl to these rust based projects? rustls - https://github.com/rustls/rustls https://github.com/rustls/rustls ring - https://github.com/briansmith/ring https://github.com/briansmith/ring If yes, then what is their experience?

cjg 5y ago
Yes - used rustls on a new project rather than the openssl wrapper which we used before. The experience has been pretty good. The problems of shared library version inconsistency have gone. No noticeable downsides.
- ris 5y ago
  > The problems of shared library version inconsistency have gone. No noticeable downsides. Sure, as long as you commit to releasing an updated version if a vulnerability is ever found in your version of rustls. Edit: oh, and in such a case you should probably release your own CVE too, else not everyone will get the nudge to update.
  - DasIch 5y ago
    OpenSSL is not great about compatibility. If you link to it dynamically, there is a good chance users have to recompile when it is updated which in practice means they'll need to update. This theoretical advantage of shared libraries also doesn't materialize, if containers are used.
    - ris 5y ago
      I do sympathize as I spend a lot of my time maintaining distro packages. But I also fear that in this new world of golang and rust projects with statically linked libraries, few people take their reporting responsibilities seriously. Hell, if they did, a serious vulnerability in a commonly used library would result in an avalanche of CVEs.
  - cjg 5y ago

jabl 5y ago

Apart from API/ABI changes, notable changes are: * Changed the license to the Apache License v2.0. * Switch to a new version scheme using three numbers MAJOR.MINOR.PATCH. - Major releases (indicated by incrementing the MAJOR release number) may introduce incompatible API/ABI changes. - Minor releases (indicated by incrementing the MINOR release number) may introduce new features but retain API/ABI compatibility. - Patch releases (indicated by incrementing the PATCH number) are intended for bug fixes and other improvements of existing features only (like improving performance or adding documentation) and retain API/ABI compatibility. See also the project's blog post about the new release: https://www.openssl.org/blog/blog/2021/09/07/OpenSSL3.Final/ https://www.openssl.org/blog/blog/2021/09/07/OpenSSL3.Final/

dariusj18 5y ago
Something I've never quite understood about semantic versioning. Sometimes fixing a bug is a breaking change, especially if someone is relying on that behavior to be bugged. How does one make the distinction?
- edoceo 5y ago
  > breaking change Seems like Major increment to me. But! If the fix is breaking some previous undefined behaviour to work correct then I think Minor with relnote. But! If the code is not in wide use, bump Patch and move on.
- dsr_ 5y ago
  If you can't re-link with the new library, it's no longer ABI compatible and thus it's a major version change. If you can re-link with the new library but something no longer works, you need to emit lots of very loud warnings when code calls that function.
- dahfizz 5y ago
  I think this is why they specifically call out ABI changes. A major release is one that changes the ABI/API - i.e. the C function definitions have changed and you are forced to recompile. A bugfix that breaks someone's workflow but does not change the ABI is not a major release.

orra 5y ago

This is the first version without the obnoxious advertising clause in the licence. Now it's Apache v2. It's a shame that OpenBSD and hence LibreSSL don't like the Apache v2 licence. Now, I think (IMHO) that's mainly OpenBSD being silly. But maybe OpenSSL should dual license under MIT OR Apache, just like Rust.

hylaride 5y ago
What's wrong with the BSD license? It's essentially as permissible as it gets...
- orra 5y ago
  There’s nothing horribly wrong with BSD licenses if you’re wanting something permissive. But there are some minor drawbacks: * there isn’t a "the" BSD licence, but a family of similar licences * MIT is similar in spirit to BSD licences, but has the advantage of being more explicit[1], for example regarding sublicensing. https://opensource.stackexchange.com/questions/217/what-are-the-essential-differences-between-the-bsd-and-mit-licences https://opensource.stackexchange.com/questions/217/what-are-... Finally, as a user, I prefer Apache over MIT because Apache makes patent rights explicit. [1] Being explicit isn't entirely academic. Cf. the historical stooshie about Pine https://en.m.wikipedia.org/wiki/Pine_(email_client)#Licensing_and_clones https://en.m.wikipedia.org/wiki/Pine_(email_client)#Licensin...
  - rdpintqogeogsaa 5y ago
    > Finally, as a user, I prefer Apache over MIT because Apache makes patent rights explicit. The thing is that you cannot really compare MIT and Apache-2.0 directly because they differ in several ways. It's not just MIT+patent clause. Disclaimer: I am not a lawyer. This is not legal advice. Consult an attorney with experience in copyright law wrt software for legal advice. Some ways they differ: 1. The MIT license does not mention patents. Apache-2.0 is explicit about patents and has active defenses (patent litigation against the one granting the license leads to immediate termination of the granted patent rights). 2. You must ship the entire license in both cases, but the mode differs. The MIT license makes you include the copyright notice and permission notice. The Apache-2.0 license makes you ship the Apache-2.0 license text in any case; this does not include attribution in and of itself, which it only mandates for redistribution in source form. 3. If you modify Apache-2.0 software, you must make modified files carry "prominent notices" thating that you changed the files (in practice, this raises interesting questions regarding workflows centered around pull requests because PRs necessarily violate the license until merged). 4. MIT license only requires you to carry around the copyright notice and the license (unless the copyright notice refers to an external file, which you must then keep under the same filename because keeping the copyright notice intact is required; fiat-crypto is one of these incredibly creative projects that does this). Apache-2.0 requires you to always also ship a file if it is a "'NOTICE' text file", assuming this means a text file called "NOTICE", you have to ship an extra file, to which you may add your own copyright notices therein. 5. No implied trademark rights on Apache-2.0. The MIT license does not make any effort to talk about trademarks (thus implied trademark licenses, like with implied patent licenses, might be possible); Apache-2.0 does not grant any trademark rights except for the NOTICE file. If you want something closer to MIT+patent clause, try the Blue Oak Model License.

teddyh 5y ago

Still no support for RFC 7250 (Raw Public Keys).

pjmlp 5y ago

A couple of double frees and memory corruption fixes, oh well.

conradev 5y ago

There are a lot of little tidbits in the changelog. For example: “Interactive mode from the openssl program has been removed From now on, running it without arguments is equivalent to openssl help.” https://github.com/openssl/openssl/blob/master/doc/man7/migration_guide.pod#interactive-mode-from-the-openssl-program-has-been-removed https://github.com/openssl/openssl/blob/master/doc/man7/migr...

hs86 5y ago

For their next release, they should rename the project into OpenTLS and go back to version 1.0. I think the advantages (it's funny) would heavily outweigh the disadvantages (everyone would hate them).

dveeden2 5y ago
It was called OpenTLS in the past. https://www.openssl.org/blog/blog/2018/12/20/20years/ https://www.openssl.org/blog/blog/2018/12/20/20years/ Would still be good to rename, but now there are other projects that use that name. Then some way to resolve the name collision is needed.

Maven911 5y ago

I wonder if and when this will be FIPS 140-2 compliant

posixplz 5y ago
I assume you mean "validated" and not "compliant" -- the distinction is important. Yes, it will be 140-2 validated. It's being submitted for testing before end of month to make the 140-2 cutoff. (September is the last month for 140-2 submissions. After September, all new FIPS submissions must be for 140-3 validation.) It's fair to assume it will take about 12-18 months from submission to certificate issuance.

wbl 5y ago

And they still haven't fixed the X509 support or the macros behind it. Run away.