Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Patch OpenSSL on November 1 to avoid “critical” security vulnerability

globalsign.com

Post reply on HN
Print view View original

131–140 of 217 posts

Re: Patch OpenSSL on November 1 to avoid “critical” security vulnerability

#131

Post by pjmlp »

bradleyjg wrote: post #119
tester756 wrote: post #37

Earlier quoted context omitted.

>You first. What browser and OS are you posting from? The ones that use Rust - Firefox and Windows

Neither Firefox nor Windows are written wholly, or even substantially, in rust. I thought “we” were rejecting programs written in unsafe languages?

True, but outside the kernel Windows has enough infrastructure running in .NET code.

Additionally even if C++ is unsafe, it is still better than plain old C, which since Vista has been the migration path from kernel code. Nowadays there are even template libraries that can be used on kernel and drivers like WIL.

Finally the Microsoft Security Guidelines are:

1 - use managed languages if one can afford it

2 - use Rust

3 - use C++, alongside SAL and Core Guidelines checkers

Re: Patch OpenSSL on November 1 to avoid “critical” security vulnerability

#132

Post by jbverschoor »

throw0101c wrote: post #114
jbverschoor wrote: post #96

Earlier quoted context omitted.

Sure, but there might also be binaries outside the distro which link things statically, because makes distribution easier. This is one of the "benefits" of go, where afaik many things are linked statically. I'm currently playing around with grepping some function-names to find out if something uses libssl, and then check if ldd to see if libssl is loaded dynamically or not.

> Sure, but there might also be binaries outside the distro which link things statically, because makes distribution easier. Then you'd use ldd to print the shared objects (shared libraries) required by each program or shared object: find … | xargs ldd . > This is one of the "benefits" of go, where afaik many things are linked statically. The static linking makes the situation worse: with dynamic link you update one…

> Every single binary that is statically linked needs to be recompiled.

Exactly my point

Re: Patch OpenSSL on November 1 to avoid “critical” security vulnerability

#133

Post by pjmlp »

progbits wrote: post #61
userbinator wrote: post #59

Earlier quoted context omitted.

I want it to be never. Controversial opinion: as long as those who use "security" to oppress us have the upper hand, code written in "unsafe languages" will always leave a path to freedom from the authoritarian dystopia of corporations and governments who will seek to increase their control over our lives. We've already seen the battle start at DRM, jailbreaking/rooting, etc. IMHO the periodic but not-too-often occur…

What are you on about? Using a library written in memory-safe language won't oppress you.

The C folks used to call Algol linage of programming languages programming with straightjacket, while we called them cowboy programming.

Unfortunately for computer security this has been a wild west.

Re: Patch OpenSSL on November 1 to avoid “critical” security vulnerability

#134

Post by pjmlp »

robalni wrote: post #78
Gigachad wrote: post #4

How many times does this have to happen before we start rejecting components written in unsafe languages?

All languages are unsafe because programming is inherently unsafe. Otherwise I look forward to the day when we stop driving unsafe cars, whatever that means. Accidents can always happen.

Indeed lets abolish seat belts!

Needless gizmos.

Re: Patch OpenSSL on November 1 to avoid “critical” security vulnerability

#135

Post by est31 »

justinjlynn wrote: post #68
JSGdev wrote: post #19

Earlier quoted context omitted.

Yep we've been using rustls for most of a year no issues. Memory safety go brrr :) Would encourage others to take a look at it. Ring is a good base that's been audited and the lower attack surface from no old openssl bloat code makes a difference.

Ring, unfortunately, has quite toxic project leadership with a history of making hostile decisions towards their contributors and userbase ( see https://github.com/briansmith/ring/issues/774 for one example ). Something to be aware of if you're considering building with it.

Generally you are right that this yanking policy isn't great, there is better tooling around to address security vulnerabilities than cargo yank by the author of the library. But it seems to me that it has been reconsidered. ring hasn't yanked versions of its library for a while, outside of one very recent yanking of an alpha release.

There are also other recent improvements, like ring used to require latest rustc very quickly, nowadays it's having MSRV's of older than six months. it also used to be impossible to link together multiple versions of ring in one binary, due to native dependencies used by ring. This issue has also been addressed thankfully.

Re: Patch OpenSSL on November 1 to avoid “critical” security vulnerability

#136

Post by rav »

jrootabega wrote: post #110

Here's the official place where these are announced, if you feel a little uneasy getting urgent security advisories from tweets and blogs: https://mta.openssl.org/mailman/listinfo/openssl-announce

Here's a direct link to the 3.0.7 announcement in the archive:

https://mta.openssl.org/pipermail/openssl-announce/2022-Octo...

Re: Patch OpenSSL on November 1 to avoid “critical” security vulnerability

#137

Post by [deleted] »

detaro wrote: post #111
rascul wrote: post #107

Earlier quoted context omitted.

It's useless because I don't know if I need to care. Vulnerabilities in openssl are nothing new so as far as I know this is just par for the course, and I get nothing out of it as of yet.

... and an announcement like this is a fairly strong message of "assume you need to care"

[deleted]

Re: Patch OpenSSL on November 1 to avoid “critical” security vulnerability

#138

Post by rascul »

detaro wrote: post #111
rascul wrote: post #107

Earlier quoted context omitted.

It's useless because I don't know if I need to care. Vulnerabilities in openssl are nothing new so as far as I know this is just par for the course, and I get nothing out of it as of yet.

... and an announcement like this is a fairly strong message of "assume you need to care"

I'm not going to assume anything in regards to a future release I have no details about.

Re: Patch OpenSSL on November 1 to avoid “critical” security vulnerability

#140

Post by drran »

jeroenhd wrote: post #99
drran wrote: post #73

Earlier quoted context omitted.

It looks like author of ring library tries to protect their user base from security vulnerabilities, but hit by bug(?) in cargo, which changed from warning to error for yanked libraries. Anyway, no promises until API version 1.0.

I don't really get the reasoning (if there's a security bug, surely you know you've fixed it?). I fully support taking down versions that have known vulnerabilities, like the broken OpenSSL crate mentioned in that discussion. The bug in cargo made the issues worse but not by much. Pulling crates/packages from the repository will break the build for almost everyone because updating your dependencies to the latest vers…

Security is a tradeoff between usability and safety. In this case, the author of ring received a suggestion from Rust security group to yank old, unsupported versions to be on the safe side, which created usability problems with ring. Security-minded people are OK with that, while security-ignorant people are not.
Post reply on HN