WIP: (building) Bump openssl to 1.0.2q

[chickenandpork]

Motivation: Security
Linked issues:

According to all-affected-spks, this will require an extensive build:

make -C spk/mutt all-supported
make -C spk/irssi all-supported
make -C spk/jackett all-supported
make -C spk/ejabberd all-supported
make -C spk/python all-supported
make -C spk/lidarr all-supported
make -C spk/radarr all-supported
make -C spk/museek-plus all-supported
make -C spk/python3 all-supported
make -C spk/homeassistant all-supported
make -C spk/octoprint all-supported
make -C spk/sonarr all-supported
make -C spk/synocli-net all-supported
make -C spk/itools all-supported
make -C spk/rdiff-backup all-supported
make -C spk/rutorrent all-supported
make -C spk/sabnzbd all-supported
make -C spk/ffsync all-supported
make -C spk/umurmur all-supported
make -C spk/boxbackup-client all-supported
make -C spk/mercurial all-supported
make -C spk/links all-supported
make -C spk/deluge all-supported
make -C spk/borgbackup all-supported
make -C spk/sabnzbd-testing all-supported
make -C spk/duplicity all-supported

... see you next week! I honestly assume something in this list will fail to build but for unrelated reasons, so there might be a pre-PR with some version-bumps that are necessary to build this one.

Checklist

• [] Build rule all-supported completed successfully
• [] Package upgrade completed successfully
• [] New installation of package completed successfully

[ymartin59]

@chickenandpork Large effort. What is specific motivation for this version upgrade? I have already python3 and borgbackup built and published waiting for activation when homeassistant will be ready too...

[ymartin59]

@chickenandpork You have proposed a PR to include your "all-affected-spks" target. This is closed today. Have you got a more recent version to submit?

[chickenandpork]

That PR was dirty from “all-affected-spks” testing. I’ll push a cleaner one.

…

On Feb 16, 2019, at 09:41, Yves Martin ***@***.***> wrote: @chickenandpork You have proposed a PR to include your "all-affected-spks" target. This is closed today. Have you got a more recent version to submit? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or mute the thread.

[chickenandpork]

Keeping SSL libraries updated tends to be a safe course of action. The testing will require more than a week of build time, but we cannot very easily have different versions of dependencies. I’ll need more horsepower to do builds faster, so it’ll be a few days. Allan

…

On Feb 16, 2019, at 09:41, Yves Martin ***@***.***> wrote: @chickenandpork You have proposed a PR to include your "all-affected-spks" target. This is closed today. Have you got a more recent version to submit? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or mute the thread.

[ymartin59]

For information, some websites (and probably many more soon) follow a "rude" recommendation to only allow TLS 1.3 because of flaw in handshake in previous TLS versions. And this requires at least openssl 1.1.1...

[chickenandpork]

So, due to big build requirements, would you suggest to make a bigger jump to OpenSSL-1.1.x ? Corporate side, we flip between different TLS libraries: the rudeness you observe might also be turning off vulnerable TLS versions due to static analysis tools flagging them as errors. This is to say: they might not be doing it to be obnoxious, but because a tool they’ve committed to honor to avoid legal risk is now alerting. It’s a hard choice between supporting customers despite risk. Given the build demand this PR entails, I don’t want to do builds on it yet until I’ve got a bigger machine up. I would estimate the dependency to cause over a week of builds on my current environment and I need to ensure at least the first build involves an empty cache.

…

On Feb 18, 2019, at 14:47, Yves Martin ***@***.***> wrote: For information, some websites (and probably many more soon) follow a "rude" recommendation to only allow TLS 1.3 because of flaw in handshake in previous TLS versions. And this requires at least openssl 1.1.1... — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or mute the thread.

[m4tt075]

For what it's worth, it seems someone tried to introduce openssl-1.1.x earlier and ran into issues with rtmpdump, and, thus, ffmpeg. At least that is written in the "Constraints" chapter of our "Update Policy" Wiki entry here:
https://github.com/SynoCommunity/spksrc/wiki/Update-Policy
With the latest ffmpeg update, rtmpdump has been removed. So at least that contraint should no longer exist. Still a major task of course. Thanks for looking into this!

[ymartin59]

@m4tt075 I did try to upgrade to openssl 1.1 and wrote that section - happy it has been useful. So we may try again and check "most" applications' compatibility.

[chickenandpork]

Possible dupe of #3560 .. working on bigger HW (for the massive build demand) so I’ll back off and see if 3560 merges.

There’s perhaps a need for automated canary and federated acceptance/bless of versions across architectures

[hgy59]

as openssl is updated to 1.0.1.u this PR got obsolete.