openssl @1.0.2h_1: update to 1.1.1c

[larryv (Lawrence Velázquez)]

I know.

​https://www.openssl.org/news/openssl-1.1.0-notes.html

[jmroot (Joshua Root)]

PyPy will not build against OpenSSL 1.1 at this point, JFYI.

[jmroot (Joshua Root)]

Replying to jmroot:

PyPy will not build against OpenSSL 1.1 at this point, JFYI.

Fixed as of PyPy 5.6.

[mf2k (Frank Schima)]

Any update on this?

It is needed for #54734.

[neverpanic (Clemens Lang)]

@larryv, any opinion on this? I think we should be good to update now. Software that hasn't been fixed to work with OpenSSL 1.1 by now is probably rare.

[mf2k (Frank Schima)]

Has duplicate #55755.

[1st1 (Yury Selivanov)]

Python 3.7 requires OpenSSL 1.1. It's not possible to build it with ssl support and OpenSSL 1.0.2.

[1st1 (Yury Selivanov)]

Nevermind, Python 3.7 compiles with OpenSSL 1.0.2n. Just use "./configure --with-openssl=/opt/local/"

[gaming-hacker (G Alexander)]

i started hacking on the portfile but there are errors trying to copy one of the headers. if you add the rfc variant, it doesn't build

version 1.1.0g checksums sha1 e8240a8be304d4317a750753321b073c664bfdd4 \

sha256 de4d501267da39310905cb6dc8c6121f7a2cad45a7707f76df828fe1b85073af

[gaming-hacker (G Alexander)]

has anyone experimented with sha3? encoding a video stream? using it over a tor socket?

[aque (Allan Que)]

I got version 1.1.0h to build on ​my branch and tests passed under High Sierra. py35-m2crypto (a port I maintain) also passed its tests. However, the following failed to rev-upgrade on my system:

• cyrus-sasl2 - requires a ​backport from 2.1.27-rc7
• rtmpdump
• cargo / cargo-stage1

xar also failed but I found and applied a patch. The others are beyond my ability. I did find a FreeBSD ​issues wikipage that helps.

[yan12125 (Chih-Hsuan Yen)]

Now here comes OpenSSL 1.1.1 LTS!

​https://www.openssl.org/blog/blog/2018/09/11/release111/

[pmetzger (Perry E. Metzger)]

Re: the 1.1.1 release:

We are on the previous LTS which only has support to the end of this calendar year, and it will take a while to upgrade, so it might make sense to begin the work now so that we can do it at a reasonable pace. 1.1.1 also is the first release with TLS 1.3 support, which we likely really really want.

[yan12125 (Chih-Hsuan Yen)]

Some old software will never get OpenSSL 1.1 compatibility as they have been dropped upstream before OpenSSL 1.1.0 is released. Examples are Python 2.x < 2.7 and 3.x < 3.5 (1). If MacPorts switches to OpenSSL 1.1, what to do with those ports? IMO backporting is not an option for old Python versions as the patch is quite big.

In Arch Linux, OpenSSL 1.0 and 1.1 co-exist, and old packages are built against OpenSSL 1.0. An issue in such an approach is that OpenSSL 1.0 should be built with versioned symbols (2) so that there are no conflicts if a program (directly or indirectly) links to both OpenSSL 1.0 and 1.1. I'm not sure if it's a problem or not in macOS/Mach-O.

(1) ​https://bugs.python.org/issue26470

(2) ​https://git.archlinux.org/svntogit/packages.git/tree/trunk/openssl-1.0-versioned-symbols.patch?h=packages/openssl-1.0

[pmetzger (Perry E. Metzger)]

We are dropping support for python below 2.7 already, as well as for python 3 before 3.4. We can start dropping before 3.5 as well.

We could start statically linking other old packages against OpenSSL 1.0 to resolve internal dependencies perhaps? Not sure if it would work. Regardless. we can't support unsupported stuff forever. It's madness in the end.

[ryandesign (Ryan Carsten Schmidt)]

Replying to pmetzger:

We could start statically linking other old packages against OpenSSL 1.0 to resolve internal dependencies perhaps?

Definitely not, for all the usual reasons why we don't static link.

[FranklinYu (Franklin Yu)]

Replying to yan12125:

Some old software will never get OpenSSL 1.1 compatibility as they have been dropped upstream before OpenSSL 1.1.0 is released. Examples are Python 2.x < 2.7 and 3.x < 3.5 (1). If MacPorts switches to OpenSSL 1.1, what to do with those ports? IMO backporting is not an option for old Python versions as the patch is quite big.

In Arch Linux, OpenSSL 1.0 and 1.1 co-exist, and old packages are built against OpenSSL 1.0. An issue in such an approach is that OpenSSL 1.0 should be built with versioned symbols (2) so that there are no conflicts if a program (directly or indirectly) links to both OpenSSL 1.0 and 1.1. I'm not sure if it's a problem or not in macOS/Mach-O.

(1) ​https://bugs.python.org/issue26470

(2) ​https://git.archlinux.org/svntogit/packages.git/tree/trunk/openssl-1.0-versioned-symbols.patch?h=packages/openssl-1.0

Would it be feasible to release a Port revision for all the affected ports?

[Schamschula (Marius Schamschula)]

I ran into a port today that can't be updated until we have openssl 1.1.1: rsyncrypto 1.14. The configure script failed Need openssl 1.1.0 or higher.

[yan12125 (Chih-Hsuan Yen)]

Replying to Schamschula:

I ran into a port today that can't be updated until we have openssl 1.1.1: rsyncrypto 1.14. The configure script failed Need openssl 1.1.0 or higher.

Then you may be interested in ​https://github.com/macports/macports-ports/pull/3783 ("openssl11: new port, version 1.1.1b").

My idea is creating a port for OpenSSL 1.1.1 and migrated away from OpenSSL 1.0.2 port-by-port. Specifically:

1. Install openssl11 to replace the openssl port on your machine
2. Make sure all ports that depend on openssl still work with openssl11. In this step port rev-upgrade is useful.
3. If a port builds with openssl but not openssl11, try to patch it
4. When all ports in the tree are compatible with openssl11, the openssl port can be upgraded to 1.1.1 and then openssl11 can be deprecated (e.g., replaced_by openssl)

[yan12125 (Chih-Hsuan Yen)]

In 06c7071fb035a1986bed0235904d247c11bebe4f/macports-ports (master):

openssl11: new port, version 1.1.1b

To make migration from OpenSSL 1.0.2 simpler. See
#52101

[aque (Allan Que)]

In 38f11ab63a2139cc8f3e32b5edb200639696df0c/macports-ports (master):

xar: patch deprecated openssl function

OpenSSL 1.1.0 deprecated OpenSSL_add_all_algorithms and replaced with
OPENSSL_init_crypto.

Ref: ​https://github.com/mackyle/xar/issues/18
Ref: #52101

[neverpanic (Clemens Lang)]

Unfortunately this plan will mean that users that have OpenSSL 1.1 installed will download binaries for software that will then immediately get rebuilt because rev-upgrade detects that it is not compatible with the installed version of OpenSSL. We should hence keep the transition period as short as possible and upgrade the main port to OpenSSL 1.1 soon, revbump the dependents and remove the openssl11 port again.

[yan12125 (Chih-Hsuan Yen)]

Replying to FranklinYu:

Would it be feasible to release a Port revision for all the affected ports?

Here's now a possible solution: ​https://github.com/macports/macports-ports/pull/3831

[yan12125 (Chih-Hsuan Yen)]

In b3f4cfbdc7ea91bff6f7be3ccc3303e1a46ce11e/macports-ports (master):

openssl10: added to simplify migration to OpenSSL 1.1

Ref: #52101
Ref: ​https://github.com/macports/macports-ports/pull/3822

[yan12125 (Chih-Hsuan Yen)]

In b07654320ec8b5b4895699bd099e34e546e9d1d9/macports-ports (master):

old_openssl: new port group for easing usage of the older openssl ports

This is a step in OpenSSL 1.1 migration.

Ref: ​https://github.com/macports/macports-ports/pull/3822
Ref: #52101

[Chih-Hsuan Yen <yan12125@…>]

In 0bb570273ea83ae95d7139752ab9d87690a2ae14/macports-ports (master):

mysql56: remove +openssl as it's incompatible with openssl 1.1

See: #58607
See: #52101
See: ​https://github.com/macports/macports-ports/pull/3822

[yan12125 (Chih-Hsuan Yen)]

In e660ba6a7265d21b28decb8f2b9a0ec4fd6541fe/macports-ports (master):

openssl: update to 1.1.1c

Closes: #52101
Ref: #58218 (old Qt5 versions)
Ref: #58607 (old MySQL versions)
Ref: #58630 (old PostgreSQL versions)