4 ms·
Every time I've seen an OpenSSL security fix on HN, the discussion gravitated towards alternatives. I think this is a wasted energy, because switching cryptogr
by some_furry 4y ago
Every time I've seen an OpenSSL security fix on HN, the discussion gravitated towards alternatives.
I think this is a wasted energy, because switching cryptographic providers is the last thing you want to do under the timeline of a routine security release for an open source library.
If you're a Debian user, this might be as simple as "ensure unattended-upgrades is configured on all hosts and this is monitored somehow". However, sometimes it's not so simple.
Eventually one of these releases is going to break something that requires a code change in your applications. (Maybe pass a different flag to OpenSSL? Maybe use a different API for, I dunno, MGF1+SHA256?) And I don't know how many teams are prepared for that kind of rollout.
I'd be interested in hearing from HN users how they plan to respond to these sort of releases.
- dochtman 4y agoThe discussion about alternatives doesn't need to be related to switching under the timeline of a routine security release, right? I would say that every security release would increase activation energy to switch to another provider, even if that happens asynchronously relative to addressing the security release. Assuming that good alternatives are available of course. (I'm a rustls maintainer, so obviously I think that's a pretty good alternative -- we have a C FFI, too!)
- some_furry 4y ago> The discussion about alternatives doesn't need to be related to switching under the timeline of a routine security release, right? If not, it certainly doesn't belong in a thread about an announcement for an upcoming security release. Maybe it'd make sense in the postmortem threads?
- Arnavion 4y agoFeel free to flag those comments and find out how many other people agree with you.