openssl_1_0_2: mark as insecure; fixes #77503 (kinda) #80746
Conversation
No vulnerabilities are know so far (to me), but still I'd go this way.
Especially for 20.03 it seems better to deprecate it before official
release happens.
Current casualties:
$ ./maintainers/scripts/rebuild-amount.sh --print HEAD HEAD^
Estimating rebuild amount by counting changed Hydra jobs.
87 x86_64-darwin
161 x86_64-linux
vcunat
added
1.severity: security
ofborg
bot
added
10.rebuild-darwin: 0
|
I'd be fine merging this into master, but disagree with backporting it to 20.03 - that should have been done before the branchoff IMHO. I'd propose keeping We probably could be backporting commits moving packages to a more recent openssl (to prepare for the fallout if it gets insecure), but with all the ZHF effort ongoing for 20.03, I don't really feel like we should fail another 161 packages on |
|
If we’re considering it, we should probably ask the RMs for their thoughts on that. Personally, I think it would be a shame to ship a release with an unmaintained OpenSSL and no warning about that. Cc @worldofpeace @disassembler |
Yes it should have, this was one very important milestone that we missed. But as @alyssais stated
I agree with this. I think it would be an understandable exception to the freeze. What do you think @disassembler? And about:
I think that amounts to the same work we'd have to do already, just more gradual?
There is no current advisory though, so I understand where @flokli is coming from since its spread is 161+87 breakages. But I'm betting that number can be reduced greatly with just a few fixes. We could make use of the buildfarm to see how much is broken. That'd be a Hydra jobset of this PR, and I think a commit substituting And users can still permit an insecure package using |
|
Well, there's probably yet another way we can go. There still are distros that will keep shipping 1.0.2 as the default for some time, so patching the worst probably won't be too difficult. Given that not too many packages depend on it, the "risk" for us isn't too high either. Still, I'm personally not willing to invest significant time into it :-) Example distros: Ubuntu 16.04, RHEL/CentOS 7. |
My rationale for doing it now is to avoid "surprises" for our users during the maintenance cycle. People will expect such regressions when switching to 20.03 but not at some point months after official release. Therefore I'd prefer to either deprecated before release in some way or "promise" that it will keep working (and reasonably secure) during whole 20.03. |
|
How does it look like on other distros?
Do they still provide some level of support, so we could use their patches?
FWIW, if the RMs agree still marking this as insecure for 20.03, and we have enough time to fix possible fallout in the critical path, fine for me too.
|
|
I wrote about some bigger distros above. |
I noticed that Ettercap was listed in #80746.
|
I'm +1 on merging this now and backporting. It doesn't permanently break people, they can still get it by allowing openssl anyway. |
|
+1 for merging it. Are the RMs accepting backports to "unbreak" some of these packages during the stabilization period? I think that would be fair game given the "late" merge of this. If nobody puts in effort to fix some of these they remain broken but at least allow invested individuals to unbreak their use case by putting in the hours. |
I think yes #80746 (comment) |
|
On that note, I'm going to fix a few things before I merge this 🤣 |
|
I need to fix gnome's evolution, it seems it fails on I believe something in perlPackages uses it . But I'm not sure how determine what. cc @jtojnar |
|
Whitelisting the insecure package, I get $ nix --option experimental-features nix-command why-depends -f . spamassassin openssl_1_0_2.out
/nix/store/47lrs5s0ggx3l315n6j3x2dixbz2pvnl-perl5.30.1-SpamAssassin-3.4.3
╚═══bin/sa-awl: …/lib/perl5/site_perl:/nix/store/01qbi7zry3w4im2q517aw5qjd8qwlraj-perl5.30.1-Crypt-OpenSSL-RSA-0.…
=> /nix/store/01qbi7zry3w4im2q517aw5qjd8qwlraj-perl5.30.1-Crypt-OpenSSL-RSA-0.31
╚═══lib/perl5/site_perl/5.30.1/x86_64-linux-thread-multi/auto/Crypt/OpenSSL/RSA/RSA.so: …0vmnx-glibc-2.30/lib:/nix/store/vg37azxslig2ysv6pnm3x3pfsbdld0ln-openssl-1.0.2u/lib.XXXXXXXXXXXX…
=> /nix/store/vg37azxslig2ysv6pnm3x3pfsbdld0ln-openssl-1.0.2uEdit: Adding |
Thanks. |
|
It is probably worth noting that we can't merge this while |
#80986 should fix it. |
|
I'm going to merge this into master and then afterwards, when we get ready to backport it, let's try to do a systemic pinging so we can get fixes. |
|
Pinging maintainers for some larger sample of the affected packages:
|
|
crystal supports 1.1 since 2018 so it should be simple to fix that in case somebody has some extra time on their hands. |
vcunat
removed
the
9.needs: port to stable
No vulnerabilities are know so far (to me), but still I'd go this way. Especially for 20.03 it seems better to deprecate it before official release happens.
Current casualties:
See also the discussion thread on #77503
20.03: /cc @NixOS/nixos-release-managers. 19.09: hopefully there won't be any notable vulnerabilities before 19.09 support ends :-)