
OpenSSL 3.0 - ddb
https://wiki.openssl.org/index.php/OpenSSL_3.0
======
JoshTriplett
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).

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

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

~~~
yc12340
> “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.

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

~~~
yc12340
> “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.

~~~
yrro
> 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)

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

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

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

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

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

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

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

~~~
jamesog
There was a proposal, which was declined:
[https://github.com/openssl/openssl/pull/8367](https://github.com/openssl/openssl/pull/8367)

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

~~~
saagarjha
“Deprecated” need not mean “insecure”.

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

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

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

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

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

~~~
fanf2
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...](https://github.com/openssl/openssl/commit/a4a90a8a3bdcb9336b5c9c15da419e99a87bc6ed)

2018-09-27: 1.1.2 -> 3.0.0

[https://github.com/openssl/openssl/commit/3a63dbef15b62b121c...](https://github.com/openssl/openssl/commit/3a63dbef15b62b121c5df8762f8cb915fb06b27a)

There weren't any releases numbered 1.1.2

~~~
ensiferum
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

------
saghm
Obvious question that it don't see answered on the page: why not 2.0?

~~~
dharmab
[https://www.openssl.org/blog/blog/2018/11/28/version/](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.

------
aorth
> _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/

~~~
NikolaeVarius
That isn't semver

~~~
aorth
What do you mean? According to [https://semver.org/](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.

~~~
NikolaeVarius
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](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.

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

~~~
pilif
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

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

------
saghul
Pity that the bits required for QUIC didn't make the cut:
[https://github.com/openssl/openssl/pull/8797](https://github.com/openssl/openssl/pull/8797)

