Upgrade: OpenSSL 3.0, make it a standard package

[slelievre]

Upgrade to OpenSSL 3.0 and make openssl a standard package.

License is now Apache 2.0, which is GPL-compatible. ​https://github.com/openssl/openssl/blob/master/LICENSE

Once Sage macOS binaries ship OpenSSL, they will allow easily pip-installing extra packages.

Download tarball from:

• ​https://ftp.openssl.org/source/

[slelievre]

OpenSSL 3.0.0-alpha1 is out. Blog post: ​https://www.openssl.org/blog/blog/2020/04/23/OpenSSL3.0Alpha1/

OpenSSL 3.0.0-alpha1 tarball:

• ​https://ftp.openssl.org/source/openssl-3.0.0-alpha1.tar.gz

[slelievre]

Time to make openssl a standard package too. Related tickets:

• #24107 Inclusion of OpenSSL, stage 1
• #23893 make openssl a dependency for pip packages

[mkoeppe]

​https://www.openssl.org/source/openssl-3.0.0-alpha3.tar.gz is out now

[mkoeppe]

Of course it's too early to merge, but I wanted to check whether our python3 compiles with it. It does, at least on macOS.

---

New commits:

​54387b8	build/pkgs/openssl: Update to 3.0.0-alpha3
​e37e813	build/pkgs/openssl/spkg-install.in: Remove old build workarounds, hoping for the best

[git]

Branch pushed to git repo; I updated commit sha1. New commits:

​d6eaab7	build/pkgs/python3/dependencies: Add openssl
​125a683	build/pkgs/openssl/type: Make standard

[mkoeppe]

Next (other than waiting for the release), we need an spkg-configure.m4 for openssl

[mkoeppe]

Now there's openssl-3.0.0-alpha4

[slelievre]

OpenSSL 3.0.0.alpha6 is out.

[mkoeppe]

alpha9 is out...

[mkoeppe]

alpha10 is out

[slelievre]

alpha11

[git]

Branch pushed to git repo; I updated commit sha1. New commits:

​48c801b	Merge tag '9.3.beta6' into t/29555/upgrade__openssl_3_0
​29af657	build/pkgs/openssl: Update to 3.0.0-alpha11

[git]

Branch pushed to git repo; I updated commit sha1. New commits:

​909f796	build/pkgs/openssl/SPKG.rst: Update license
​383a100	build/pkgs/openssl/spkg-configure.m4: Add warning about alpha release

[mkoeppe]

Wondering how people would feel about this one. Solves our openssl license compatibility problem. Includes big fat warning that it's an alpha release. To my understanding, the way that current jupyter depends on the ssl module (via tornado - see 30674), it is merely a dependency and no SSL is actually spoken to anyone but possibly localhost.

SSL would still kick in when pip packages are installed - but these are all optional and users have been warned.

[tmonteil]

I would prefer that we stick to 1.1.1* until openssl 3.0 is released, the current 3.0 is not even beta !

[dunfield]

Replying to tmonteil:

I would prefer that we stick to 1.1.1* until openssl 3.0 is released, the current 3.0 is not even beta !

Currently, the macOS binaries don't have any version of openssl at all. So there, the choice is 3.0 alpha or nothing, meaning the user is unable to run Jupyter notebooks, which is a pretty core feature of Sage for many users.

I say go for it, the current situation is causing a lot of people problems, see all the posts to sage-support and sage-devel.

[tmonteil]

Could this be only shipped with macOS binaries ?

[dunfield]

Replying to tmonteil:

Could this be only shipped with macOS binaries ?

On Linux, Sage doesn't need to provide its own copy of openssl, it just uses the system library. The problem is macOS deprecated openssl in favor of their own APIs and only provides openssl 0.9.8, which is too old to be useful.

[mkoeppe]

Another idea could be to make openssl 3.0 standard (as on this ticket) but keep the stable (but license-incompatible) openssl 1.1.x as an optional package. So people who need to deploy a secure system but cannot do so using a system installation of openssl would be enable this optional package. But it is not clear whether this is a convincing use case that would warrant adding this kind of build system complexity for it.

[mkoeppe]

Replying to tmonteil:

Could this be only shipped with macOS binaries ?

These issues with ssl also affect people who build from source.

[dimpase]

I suppose this is tested on macOS. On Linux it's fine.

[tmonteil]

Replying to mkoeppe:

Replying to tmonteil:

Could this be only shipped with macOS binaries ?

These issues with ssl also affect people who build from source.

I imagine the people that build from source use a decent distribution of packages that includes openssl like homebrew, as recommended in the Sage installation documenation.

I do not like the current way as it will install an immature implementation of SSL within Sage for most people, since even on some OS that ship openssl-dev, this latter is rarely installed by default, see e.g. ​https://ask.sagemath.org/question/47513/rise-in-jupyter/

The warning are probably not enough (and probably lost among tons of configure lines) since people will just go ahead and "prefer" using the standard openssl spkg over installing the lib from their distro.

[slelievre]

I'm also uneasy with an alpha stage OpenSSL 3 becoming standard.

Maybe we can create an "openssl3" optional package for now?

We should advertise the fix_mac_sage scripts by the 3-manifolds group

• ​https://github.com/3-manifolds/fix_mac_sage/

that can "fix" a Sage install on macOS by adding SSL and tkinter to its Python.

We should advertise it

• in the README file that is shipped with macOS binaries
• on the macOS download page of the SageMath website