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
* 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.
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?
Remember, versioning rules are like D&D. The purpose of the rules is to give you a framework to operate in that is easily understood in the vast majority of situations, not to comprehensively define every aspect. You don't get any rewards for following the rules, after all. When things get weird, you just ask the DM, they make a ruling, and then you keep the game moving forward.
There's always going to be corner cases. Fortunately, there is always a person available to act as a referee.
If the bug wasn't documented and the user effectively relied on "undefined behavior" I don't think it constitutes a breaking change. Like if a function called with certain parameters causes an unexpected crash, and a user decided to use that to quit the application, you can't reasonably be expected to maintain that behaviour.
If the bug was that a well documented function actually behaved differently than was expected but still consistently (like a string function that was supposed to return a number of characters but really returned a number of bytes) then yeah, that's a breaking change.
In practice the line can be fuzzy of course, but I find that it's not usually to hard to decide what constitutes a breaking change and what doesn't.
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.
Apart from the ABI thing, which is pretty clear-cut - most bug files should not break the public Api - but sometimes the api spec is buggy. Then bug fix becomes a breaking change.
Assume that ssl certs are never actually checked[1] - this is typically a bug - and a bad situation. I would probably assume fixing such a bug would be a breaking change, even though it's a case of "omg, hair on fire this never was working" - and clearly a bug...
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.
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.
Well our product was already something that included the openssl library, so we would have had to release a new version of our product when there's a patched version of openssl anyway.
At least updating it is easy now - we've put a lot of effort into that process recently.
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.
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.
Plenty of rust-based projects are using these libraries. I've yet to hear of a bad experience. I don't think there's much adoption outside of the Rust ecosystem.
For a newer project I'm surprised their documentation makes this recommendation:
> Next we load some root certificates. These are used to authenticate the server. The recommended way is to depend on the webpki_roots crate which contains the Mozilla set of root certificates.
The correct certificates to use are the ones that the OS says are trusted. Applications shouldn't ship with a cert bundle that overrides what I trust.
I've used rustls with great success, and I'm really happy with it. Many projects have added support for it, such as curl.
However, I also still really welcome this announcement! There's a lot of code out there using OpenSSL, including both well-established libraries and new projects. I'm glad to see a new stable version of OpenSSL, with a better overall architecture and a more compatible license.
I get stuck in a weird bug on certain Customer machine that suddenly start failing, so I replace the http client library to one that use rustls and gone.
A few hours of work and also the CI benefit!
P.D: Other software also fail the same, but they can't switch so fast... Rust refactoring is golden!
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.
> OpenBSD is not being "silly" they have solid reasons
They're entitled to their opinion, but I'm entitled to think they're silly.
In particular, it's weird that they hate the termination clause of the patent grant in the Apache licence, when BSD licenced code doesn't even contain an explicit patent licence.
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.
I don't think they like patents in their licenses at all.
> 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.
> 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).
Yeah, having to do this on each individual file is an unnecessary burden.
Edit: It seems, for example, gratuitous to insert a copyright line for yourself, if your patch is only a couple lines long.
MIT explicitly permits merging, publishing, sublicensing, and selling. BSD isn't explicit about it. BSD 2, 3, and 4 aren't explicit about that. Some people (e.g., lawyers) care about licenses being explicit rather than relying on implicit phrases like "any purpose" which sound rock solid but can still technically be argued about in court.
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.
- 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/