OpenSSL 3.0 | Hacker News Reader

OpenSSL 3.0

wiki.openssl.org

243 pointsddb104 comments

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: 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).

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".

> Other major improvements: TLS1.3 support

OpenSSL 1.1.1 already supports TLS 1.3

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.

There is no reasonable way that the old license will ever go away unless they do a relicensing effort like OpenSSL did. They won't, so it won't.

You're most likely correct.

I was just pointing out that libressl is not under a different license from openssl < 3.0 as a whole, nor is it under the openbsd license as a whole. Rather parts of it are under the old openssl + ssleay dual license, and other parts are under the openbsd license. And over time, the fraction under the openbsd license is bound to increase, although as you say, they will probably never reach the point where all the old code has been replaced.

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.

Why do they hate APL?

If you mean Apache License then,

The original Apache license was similar to the Berkeley license, but source code published under version 2 of the Apache license is subject to additional restrictions and cannot be included into OpenBSD. In particular, if you use code under the Apache 2 license, some of your rights will terminate if you claim in court that the code violates a patent.

A license can only be considered fully permissive if it allows use by anyone for all the future without giving up any of their rights. If there are conditions that might terminate any rights in the future, or if you have to give up a right that you would otherwise have, even if exercising that right could reasonably be regarded as morally objectionable, the code is not free.

In addition, the clause about the patent license is problematic because a patent license cannot be granted under Copyright law, but only under contract law, which drags the whole license into the domain of contract law. But while Copyright law is somewhat standardized by international agreements, contract law differs wildly among jurisdictions. So what the license means in different jurisdictions may vary and is hard to predict.

- https://www.openbsd.org/policy.html

Thanks for this excellent explanation.

Great explanation!

Dumb question here, isn't a license already a contract in the first place?

Not a dumb question at all -- that's actually fairly controversial.

Many licenses are offered as part of a contract. But in _most_ jurisdictions (albeit not the one I'm standing in, which is Scotland) in order to have a contract one must have both a meeting of the minds and consideration. Many Free licenses don't have either. So they rely on copyright law: you don't have to agree to the license terms. If all you're doing is stuff that's allowed under law, you're fine. If you want to do something beyond that, you need permission and the license is what supplies permissions.

This is also where the "viral" nature of GPL licenses has its controversy: if the license is a contract, then you've agreed specific actions to take in order to be able to derive from the source. So (while it's not likely) a court could compel specific performance of that action, forcing you to release your code under the GPL (viral!). If it's not a contract, then by not agreeing to the terms you may have breached copyright, but there's no mechanism for anyone to _force_ you to do anything except stop breaching copyright. So no possibility that you will be required to release your source.

So you may be better off thinking of the license as a thing that may be bought or sold using a contract, but is itself not a contract. Proprietary software will often be bought or sold like this: you're not buying _the software_, you're buying _a license to use the software_. Where Free software licenses are often (but not always!) available for free.

But some licenses start looking like they stretch beyond the realm of pure copyright licenses, and that's where the controversy picks up again.

How do shops work in those jurisdictions? Don't they usually rely on an ‘offer’ that is semi-implicitly accepted by a client? And which is afaik a form of contract? I thought that this is the mechanism that licenses use.

This seems to be the thing in English: https://en.wikipedia.org/wiki/Offer_and_acceptance

User andinus provided the official explanation given by the openbsd project.

On a more philosophical level, the more radical end of the BSD licensing champions such as openbsd are extremists, just like the FSF/GNU people on the other end of the spectrum. Both want a world where ultimately software copyright, not to mention software patents, doesn't exist, source is available for everything and you can use that source for any purpose you like etc. They just have different ways of working towards that goal. The GNU end came up with a legal trick to use copyright law to try to force people to open up their software (copyleft licensing), whereas the BSD radicals just wish the whole copyright crap would go away and thus use the simplest possible license they can come up with.

So the Apache-2.0 license, although in many ways a BSD-like license, is written by and for corporate lawyers, which grates the openbsd people to no end.

"extremists"? Really?

If anything the folks who want software copyrights and patents are the "extreme" POV, no?

I mean, on the hardware level we're talking about MOV instructions, eh?

Uh, maybe I should have worded that differently. I didn't mean "extremist" as a value judgement. Just someone being on the extreme end of the spectrum "all software should be free" vs. "all software should be proprietary and patented".

Edit: And now I see that in my grandparent post I wrote that the BSD and GPL people are extremists on opposite sides of the spectrum, which doesn't really match the above. I don't know what I was thinking when I wrote that, what I wanted to write was that they are both on the same end of the spectrum.

Cheers! We're cool.

(FWIW I think it's a high-dimensional manifold, not a spectrum. But I feel ya.) ;-)

A bit of a digression: the Apache license includes better patent language, which got me thinking of the patents on ocb mode. Shouldn't they expire sometime early in this decade? Like next year or something?

Rogaway has licensed them to any TLS implementation for free.

...wasn't the major reason to avoid it the shitton of vulns it has had compared to libreSSL!?

The “shitton of vulnerabilities” is a recent phenomenon, it’s not what prevented people from using OpenSSL.

Perhaps a recently discovered phenomenon.

It definitely should be the reason now!

- 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...

Yes it supports Kernel TLS offload support. Both in SW mode (where the kernel does the TLS operations) and HW mode https://www.kernel.org/doc/html/latest/networking/tls-offloa...

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?

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.

> “GPLv2 or later” cannot be changed to either GPLv2 or GPLv3 only without permission...

What? Of course it can be changed to either. It literally says so in the license name.

No, it does not say such thing. “GPLv2 or later” says you are allowed to use it under GPLv2 or GPLv3 (for now). It does not allow to change it to GPL-2.0-only (to use the correct SPDX identifier).

> “GPLv2 or later” says you are allowed to use it under GPLv2 or GPLv3

I am afraid, that you are wrong. GPL does not govern usage of software at all. You don't need to agree to GPL in order to use GPL licensed software. This is literally said in text of GPL itself.

The preamble ("this program is free software...") is not part of GPL itself — it is just short informative text. And you are misremembering, what preamble says. Citing from GNU website:

> This program is free software: you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation, either version 3 of the License, or (at your option) any later version.

I believe, that we should erase all SPDX-whatever nonsense from Linux source code, and replace it back with proper preamble — least other users of GPL software start to misremember as well.

the SPDX short identifiers are a great way for people to misunderstand how the license works. The preamble that the FSF suggests makes it clear what it does, why it works that way, and how you can leverage it.

> You don't need to agree to GPL in order to use GPL licensed software.

I've wondered for some time how a user is granted permission to use GPL-licensed software; permission is not explicitly granted by the GPL, but it is required so that the user can copy the software to their computer, and into memory for it to be executed, is it not?

(I am aware that the answer will vary by jurisdiction)

The GPL does not explicitly grant permission to use the software, that is true. However, its terms are clear about the conditions in which you lose that right.

If I take a GPLv2-or-later work, change the license notice to say GPLv2-only (or GPLv3-only, or GPLv3-or-later), and distribute it with that modified notice, have I violated the copyright licenses or copyright law? IANAL but I believe the answer is "No".

Now, if all I've done is change the license notice, my change is legally ineffective – anyone who receives it from me can change it back to the original GPLv2-or-later, and I have no legal recourse against them. However, if at the same time as changing the license, I also make (non-trivial) modifications to the code, then recipients cannot legally change the license back to the original GPLv2-or-later without either reverting my code changes or seeking my permission. (This is because I own copyright in my code changes as a derived work.)

> IANAL but I believe the answer is "No".

The answer is "Yes".

Think about it this way: the license is "GPLv2 or later", not "GPLv2" or "GPLv3". If you change the license notice, you are changing the terms in which people will receive the code from you. The GPL (both of them) clearly says you cannot do this. You have to distribute modified works under the exact same terms you received the original work, or you lose the right to use the software (both original and modified) yourself if you violate its licensing terms.

The standard wording for a GPLv2-or-later license (as recommended by the appendix of GPLv2 itself) is:

> This program is free software; you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation; either version 2 of the License, or (at your option) any later version.

Per that notice, I have an option of distributing it under the terms of GPLv2, or under the terms of the GPLv3, or even a GPLv4 if the FSF were to someday publish one. So, I decide to make use of that option and distribute it under the terms of the GPLv3.

You can't argue that from the text of the GPLv2 or GPLv3 that I don't have the option which the license statement says that I do. The license statement applying the GPLv2 (or GPLv3) text is of greater authority than the text of the GPL itself. You can't use the later to cancel out the option granted by the former.

The license is allowing you to perform specific actions. You can modify the work or redistribute it under the terms of "GPLv2 or later" without losing any of the rights the original copyright holder(s) passed on to you.

For a "modify and/or redistribute" example, under this "GPLv2 or later" licensing you can modify the software and use it in a SaaS without having to distribute it (which the GPLv3 would force you to), because you can choose to follow the terms of the GPLv2.

Likewise, you can use it and demand/assume implicit patent grants from the copyright holder, which the GPLv2 says nothing about, but the GPLv3 does.

Changing the license of the work is not modifying the work. That is the key difference. You must pass the same set of rights which you have received, like I said in other places. You can modify the work, but you cannot relicense the work. Only an original copyright holder can do this (for its part of the code).

When someone licenses software under the GPL (any of the versions), he/she isn't giving recipients any rights over licensing, he/she is only defining how the software can be modified and distributed.

Edit: To be clearer, a specific GPL version says you must pass that specific version's rights when you distribute. This makes it look like when you choose a version, you only need to pass that version's terms along. However, general copyright law (in most places) says you need to be explicit, so, if the GPLvX doesn't say you only need to pass those rights, then you need to pass those rights and any other (perhaps optional) rights.

> For a "modify and/or redistribute" example, under this "GPLv2 or later" licensing you can modify the software and use it in a SaaS without having to distribute it (which the GPLv3 would force you to), because you can choose to follow the terms of the GPLv2.

GPLv3 says absolutely nothing about SaaS. You're thinking of the AGPLv3. The only thing GPLv3 does in that regard is declare itself compatible with the AGPLv3, so you can combine code under those licenses.

IANAL. I'm more familiar with GPLv3-or-later because it's how I license Red Moon, but I assume v2-or-later uses the same phrasing, which I got from the FSF website iirc:

> Red Moon is licensed under the GNU General Public License version 3 or (at your option) any later version by the contributors.

As this reads to me, I am offering you a choice of licenses. You may use Red Moon under the GPLv3, or you may choose a later version of the GPL. Or, you could choose both, if you wish to distribute your derivative as GPLv3-or-later.

Put differently, a GPLv2-or-later currently means a dual-license, under both v2 and v3 (and an automatic relicensing to triple license if v4 is released, etc).

The FSF does not do GPLv3-only, they do "GPLv3 or later" for their projects (or "LGPLv3 or later" if applicable).

(This is not legal advice, but I do deal with software licenses professionally.)

> 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.

This is not the case. A dual license allows you to redistribute under one or the other license, or both. "GPLv2 or later" must necessarily allow distributing under GPLv2 or GPLv3, because otherwise it wouldn't be compatible with GPLv2 or GPLv3. You're also free to combine it with GPLv2-only code (in which case you must distribute under GPLv2-only), or GPLv3-or-later code (in which case you must distribute under GPLv3-or-later).

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

The FSF requires copyright assignment, but that's not why; any project under GPLv2-or-later may be changed to GPLv3-or-later. And new code would then be contributed under GPLv3-or-later.

Also, the FSF doesn't like to use "GPLv3 only", for the same reason they don't like to use "GPLv2 only". FSF projects under GPLv2-or-later switched to GPLv3-or-later.

> How can a license be incompatible with only the latter then?

Your parent comment said no such thing. It says, that you need GPL v3 to be compatible with Apache 2. "Or later" clause on GPL 2-licensed project offers you a way to re-license the project under GPL v3.

This is where some BSD folks get frustrated by some GPL folks. Compiling code under BSD with code under GPL into the same binary is not _relicensing_. Each section of code still has the same license, and any binaries must abide by the intersection of the licenses. It is indeed the case that the intersection of GPL and BSD is equivalent to GPL and therefore allowed by the GPL, but the BSD license remains on the portions (of code and of binary) that are BSD licensed.

Wouldn't it be the union of the licenses, not the intersection? Provisions of one license wouldn't go away because they're not present in the other?

Think "most restrictive", when he says intersection. You can only do things allowed by all of them.

I read it as intersection of the permissions is a union of restrictions. So, I think the point is that given the union of the restrictions, you get the most restrictive license in this case, the GPL.

Thanks Josh, that's a helpful summary!

> 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.

Does this mean I cannot use openssl in my gpl-2.0-only program? How does that work? Doesn't gpl-2.0-later imply that I can also take the code and use it in gpl-2.0-only?

Is there some tldr on this topic somewhere? I'm not good with these legal things to ELI5 would be nice :/

> Does this mean I cannot use openssl in my gpl-2.0-only program?

Correct.

> How does that work?

The GPL 2.0 and Apache-2.0 licenses contain terms which are incompatible with each other.

> Doesn't gpl-2.0-later imply that I can also take the code and use it in gpl-2.0-only?

Yes, in that case you can choose whether you use the code subject to the gpl 2.0, 3.0 or any later version. If you combine that code with some gpl-2.0-only code then you're choosing to use the first code under 2.0, and the combined work is then gpl-2.0-only.

> Is there some tldr on this topic somewhere? I'm not good with these legal things to ELI5 would be nice :/

The GNU project maintains a list of licenses and some comments about them, and conveniently categorizes them according to their GPL compatibility.

https://www.gnu.org/licenses/license-list.html

See also the chart at http://gplv3.fsf.org/dd3-faq for compatibility between the different GPL versions and variants.

> > Does this mean I cannot use openssl in my gpl-2.0-only program?

> Correct.

Well that sucks. I guess I'll need to look into libressl.

You might also check out GnuTLS which is under the LGPL 2.1+ license. If you're using Linux it's certainly already available from your package manager.

>I guess I'll need to look into libressl.

libressl is under the original openssl license which is GPL incompatible.

> > Does this mean I cannot use openssl in my gpl-2.0-only program?

> Correct.

Wait, I've tried to do some more reading and there are some things I do not understand:

1. I've done quick search over pacman database, and there are lot of packages that are either gpl or gpl2 that link against openssl. Does that mean that archlinux should be in deep legal trouble and it needs to drop few hundred packages (including coreutils, libgit2, kmod and others). Hell, even git itself links again openssl and that is gpl-2.0-only project. Does this make git illegal?

2. Are the "legal issues" comming from gpl-2.0-only side or from the openssl side? If from the gpl-2.0-only side, cannot I just add linking exception to the license to explicitely allow linking to openssl?

The GPL has an exception for linking with system libraries. It's quite arguable that OpenSSL is one of them. The legal issues are coming from the GPLv2 side, yeah.

https://en.wikipedia.org/wiki/OpenSSL#Licensing

It's somewhat(?) common for GPL projects to add an exemption to the license to allow it to be linked to openssl. See e.g. https://people.gnome.org/~markmc/openssl-and-the-gpl.html

In other cases, there's the "system library" argument (the GPL contains language that if a library the program links to is a "system library" the GPL "virality" doesn't extend there).

And in yet other cases, people just ignore it.

If you want to play it safe, just use GnuTLS, or Mozilla NSS.

If you are the copyright holder, you can put a OpenSSL exception clause in your license which allows this to work. Debian requires such a clause for GPL software to link with OpenSSL prior to this change.

It's incredible how much time and energy is spent on what license things use.

But think of what the gpl has given to us!

> TLS1.3 support

TLS 1.3 support was already added in OpenSSL 1.1.1

https://www.openssl.org/news/openssl-1.1.1-notes.html

> 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).

> 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).

I'd guess it's there to support cryptographic protocols that require downloading/checking keys via HTTPS. Right before that line is "Implementation of the Certificate Management Protocol (CMP, RFC 4210) also covering CRMF (RFC 4211) and HTTP transfer (RFC 6712)".

And yes, use curl.

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.

HTTPS is a really huge scope to tackle, and requires a lot of policy which OpenSSL traditionally hasn't encoded (how to root trust, for example — possibly involving system stores or custom ones, stapling, pinning…). Also, OpenSSL generally is embedded in HTTP clients, and having distinct implementations of HTTP calling into each other from the same library seems terrible, with potential for security issues related to policy or implementation mismatches.

Of course, there's all the traditional bug surface of any code that talks to the network to consider as well.

Defining an interface for calling back into another HTTP library might be doable, but there's still a question of scope creep.

The motivation seems to be this fork and pull request:

- https://github.com/mpeylo/cmpossl

- https://github.com/openssl/openssl/issues/5926

The use case is far away from what most users of OpenSSL need, and could quite easily be tackled outside OpenSSL.

I don't have much familiarity with OpenSSL and crypto scares me away from reading the sources. I wish someone could give a full run-down of everything that is in OpenSSL, an overview. You hear all the time about it being bloated and supporting too many things. I wish I better understood that. It's why people turn to wolfssl and mbedtls, right?

Smaller projects that aim for minimalism and robustness probably suffer from a lack of peer review with a more niche community backing them. Trade-offs trade-offs. I also wish I understood where they compete:

OpenSSL <-> WolfSSL <-> mbedtls

> It's why people turn to wolfssl and mbedtls, right?

I tried to use a single algorithm from OpenSSL for an embedded project and seems like it needs hacking for all the dependencies to be met. I gave up. With mbedTLS it was done within a minute (simpler to build and read IMO).

There aren't many differences between mbedTLS and WolfSSL. Both are small libraries designed for embedded use. The latter supports TLS 1.3.

Today OpenSSL probably has the best support for hardware acceleration and secure elements.

I had not considered that it may have support for hardware accelerated crypto.

The documentation already has an overview: https://www.openssl.org/docs/manmaster/man7/

That goes a long way, thank you :-) One of the other comments was saying OpenSSL probably has the best support for secure elements (hardware accelerated crypto?).

don't forget BearSSL[1]!

[1]: https://bearssl.org

There is a fascinating and funny talk by Bob Beck from OpenBSD on the first 30 days after forking OpenSSL. One of the things he addresses is the scary code and how is prevents community involvement. He also talks a great deal about all that stuff that's not really relevant anymore and how much they removed from the LibreSSL source code.

Apparently the crypto modules are pretty well made according to the OpenBSD developers.

LibreSSL: The first 30 days, and what the Future Holds: https://www.youtube.com/watch?v=oM6S7FEUfkU

There's simply no way anybody will confuse OpenSSL 3.0, SSL 3, and TLS 1.3 :-)

Came to the comments to try understand why SSL 3 was on HN.

This link should be named OpenSSL release 3.0

I'm confused as to why they didn't skip a version release; for clarity's sake.

There was a proposal, which was declined: https://github.com/openssl/openssl/pull/8367

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.

As an initial upgrade, that is a decent strategy. Staying behind is even more insecure.

It's mostly about deprecating old APIs where a newer more general API is available, sometimes for more than 10 years.

Deprecated can mean anything. They cannot remove any function due to being a C shared library. Removing functions or global symbols would break linking and runtime initialization.

As important as openssl is for many projects I find the engineering quality of it to be lackluster. My project is still on an older version and I wanted to upgrade. I tried to build approximately 7 versions for windows using msvs 2017 and msvs 2019. None even build but fail with compiler errors or linker errors!

On Linux if I go to system provided 1.2.x openssl version and try to build against that my code breaks with thousands of mysterious errors about undefined types (in openssl headers).

I mean Openssl solves a big problem but from engineering perspective the library is one giant problem. And I haven't even remarked on the horrible API design yet.

I've mixed opinions over the recent breakages I've witnessed in OpenSSL.

On one hand, I absolutely hate a library which breaks its API (I think lack of stability in interfaces is one of the bigger bane of the software industry and causes numerous issues down the line).

But in the specific case with OpenSSL, the breakages are legitimate imho. Most of the breakages I have seen are to clean-up interfaces and have a clear boundary between OpenSSL internals and items controlled by third party apps.

Concretely, they are switching from an API which exposed the internal structures directly to a getter/setter pattern.

Example in from one of my project:

old:

  ts_response->tst_info->serial

new:

  TS_TST_INFO_get_serial(TS_RESP_get_tst_info(ts_response))

Breaking APIs is always a balancing act, it's not something which must happen willy-nilly, but it's sometimes a necessary evil, and in the specific case of OpenSSL, if the project wants to go forward and improve in quality and stability, they are kind of forced to do it, it's just a bit regrettable that better design decisions had not be made from the start.

I'm not even talking about clear cut API breakage. I'm talking about that if I do #include <openssl.h> and build against the 1.2.x system installed OpenSSL I will get thousands of errors from headers internal to OpenSSL.

There's no such thing as OpenSSL 1.2

2018-09-11: 1.1.1-> 1.1.2

https://github.com/openssl/openssl/commit/a4a90a8a3bdcb9336b...

2018-09-27: 1.1.2 -> 3.0.0

https://github.com/openssl/openssl/commit/3a63dbef15b62b121c...

There weren't any releases numbered 1.1.2

Sorry you're right I mixed up the version numbers. It was 1.1.x that I wanted to upgrade to from 1.0.x

Obvious 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.

> 1.7 Versioning Scheme

> The OpenSSL versioning scheme has changed with the 3.0 release. The new versioning scheme has this format:

> MAJOR.MINOR.PATCH

Yay. OpenSSL finally switches to semantic versioning. \o/

That isn't semver

What do you mean? According to https://semver.org/:

> Given a version number MAJOR.MINOR.PATCH, increment the:

> MAJOR version when you make incompatible API changes, > MINOR version when you add functionality in a backwards compatible manner, and > PATCH version when you make backwards compatible bug fixes.

> Additional labels for pre-release and build metadata are available as extensions to the MAJOR.MINOR.PATCH format.

Seems like semantic versioning to me! At least the major, minor, and patch will mean something now.

SemVer is a spec. In the same way that people for some reason think that Terraform is SemVer just because it LOOKS like it even though nothing actually claims that they are using SemVer https://github.com/hashicorp/terraform/issues/15839

The only thing that OpenSSL claims to enforce about their versioning policy is

> A change in the second (MINOR) number indicates that new features may have been added. OpenSSL versions with the same major number are API and ABI compatible. If the major number changes then API and ABI compatibility is not guaranteed.

I 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..

This release actually seems less painful than 1.1 which broke a lot of APIs.

The plan at least is that at little as possible should break. If you do find a problem, please file an issue.

From other threads it sounds like the licensing may turn out to be a larger pain point than any backwards incompatibility in the code.

Pity that the bits required for QUIC didn't make the cut: https://github.com/openssl/openssl/pull/8797

Reply on news.ycombinator.com