openssl bad link

[benczaja]

during the initial install of muscle (C++) building local openssl seems to have a bad web address.

the address https://www.openssl.org/source/openssl-1.1.1c.tar.gz can not be resolved.

See full output here...

Building local openssl... make -C openssl make[4]: Entering directory '/mnt/c/Users/Ben/Desktop/muscle3_source/muscle3-0.2.0/libmuscle/cpp/build/grpc/openssl' wget https://www.openssl.org/source/openssl-1.1.1c.tar.gz --2020-04-07 12:52:02-- https://www.openssl.org/source/openssl-1.1.1c.tar.gz Resolving www.openssl.org (www.openssl.org)... 2a02:26f0:f4:3ae::c1e, 2a02:26f0:f4:388::c1e, 104.98.131.48 Connecting to www.openssl.org (www.openssl.org)|2a02:26f0:f4:3ae::c1e|:443... connected. HTTP request sent, awaiting response... 404 Not Found 2020-04-07 12:52:02 ERROR 404: Not Found.

[LourensVeen]

Ah, looks like we're at 1.1.1f now, so the installer should be updated to get the latest version. Or maybe it should try to auto-download the latest version, because otherwise I'll end up doing a patch release for MUSCLE 3 every time OpenSSL updates to keep things secure, and that's not optimal and failure-prone.

If you can install packages, then installing the openssl or openssl-dev (depending on Linux distribution) package should work around this, as it should then pick up the system version and not try to install OpenSSL itself.

[LourensVeen]

Note that this is not per se a security issue, because in the context of MUSCLE 3, OpenSSL is used only by gRPC for setting up encrypted links. We use gRPC to communicate between the instances and the Manager, but we use an unencrypted link, so OpenSSL is really only needed to get it to compile, it's never actually used.

Of course, we do leave an OpenSSL installation on the system that someone may decide to use for real, and since it's not managed by a package manager with automatic updates, it'll probably go out of date and become insecure. That's bad.

We could avoid this by always relying on a system installation, but this may make it more difficult to use MUSCLE 3 on clusters, since one would have to ask the admins to install it. This could be mitigated by getting MUSCLE into Conda forge, assuming that that has OpenSSL and the other dependencies available.

For now, just try to discover the latest version at least.

[LourensVeen]

Actually, the system package for OpenSSL is libssl-dev, at least on Ubuntu, not openssl.

[LourensVeen]

Oh, this is weird. I'm trying to reproduce this, and I can't. The file downloads just fine:

wget https://www.openssl.org/source/openssl-1.1.1c.tar.gz
--2020-04-18 20:11:01--  https://www.openssl.org/source/openssl-1.1.1c.tar.gz
Resolving www.openssl.org (www.openssl.org)... 2a02:26f0:6b:29a::c1e, 2a02:26f0:6b:28b::c1e, 104.98.131.48
Connecting to www.openssl.org (www.openssl.org)|2a02:26f0:6b:29a::c1e|:443... connected.
HTTP request sent, awaiting response... 200 OK
Length: 8864262 (8.5M) [application/x-gzip]
Saving to: ‘openssl-1.1.1c.tar.gz’

openssl-1.1.1c.tar.gz         100%[===============================================>]   8.45M  1.32MB/s    in 6.3s    

2020-04-18 20:11:08 (1.34 MB/s) - ‘openssl-1.1.1c.tar.gz’ saved [8864262/8864262]

I had assumed that they removed older packages to avoid people accidentally installing a version with known security issues, but maybe this was an intermittent issue?

[LourensVeen]

Since this only happened on Windows Subsystem for Linux, seems like an issue with the server, and is not currently of importance to the reporter, I'm going to close this issue. If it pops up again, please reopen and we'll have a go at debugging it.