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

81–90 of 217 posts

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

#81

Post by justinjlynn »

drran wrote: post #73
justinjlynn wrote: post #68

Earlier quoted context omitted.

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.

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.

That's a rather charitable interpretation of events. Events which didn't need to happen. Events which happened for dubious reasons and which depended dubious reasoning.

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

#82

Post by justinjlynn »

tpxl wrote: post #80
justinjlynn wrote: post #68

Earlier quoted context omitted.

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.

That looks reasonable to me. The author is blunt about how he does things and why he does them, while being polite. Don't know what 'yanking' a crate means specifically, but that seems like an ecosystem problem; in Java for example, maven dependencies are supposed to be immutable and the largest distributor (mvnrepository) doesn't allow updating a package.

Yanking crates makes them entirely unavailable for downstream users unless they've already locked the yanked version locally. This breaks dependencies and unlocked builds. Yanking crates is a last resort measure (a fundamentally broken release or a release for which you've issued a security advisory) and not something which should be done trivially regardless of whether or not it breaks all of your users for reasons related only to one's own conflicts of interest (i.e. You won't support it because the person asking you doesn't have a support contract). The author is most certainly entitled to be blunt about their support policy. They are not entitled to disregard community conventions when using community provided package hosting services.

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

#83

Post by komuW »

stigz wrote: post #31
fulafel wrote: post #17

Earlier quoted context omitted.

The start has happened, but it's happening unevenly with different users. Lots of TLS servers (in reverse proxies but also in backend apps and even Apache httpd[1]) are in memory safe languages. For example Go, while not totally memory safe, has shipped their Go-implemented crypto/tls library for a long time. (And also had some crypto correctness bugs - reminding us that memory safety is "necessary but not sufficient…

Speaking of go, it looks they will be patching this as well. https://groups.google.com/g/golang-announce/c/dRtDK7WS78g

Filippo Valsorda(FiloSottile), who is the maintainer of Go's cryptography libraries said on Go's slack channel that the patch is unrelated.

See screenshot of the slack conversation: https://paste.pics/f5622033ae711b36e0bbcda393a67866

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

#84

Post by komuW »

timdoug wrote: post #30
speedgoose wrote: post #20

Earlier quoted context omitted.

Not OS or browser but my SSH servers use Teleport and my HTTPS servers use Traefik or Caddy. Caddy, Traefik, and Teleport are written in Golang and not using OpenSSL. It’s a start.

I adore Go, but it seems to be impacted too: https://groups.google.com/g/golang-announce/c/dRtDK7WS78g

Filippo Valsorda(FiloSottile), who is the maintainer of Go's cryptography libraries said on Go's slack channel that the patch is unrelated.

See screenshot of the slack conversation: https://paste.pics/f5622033ae711b36e0bbcda393a67866

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

#85

Post by komuW »

timdoug wrote: post #34
woodruffw wrote: post #32

Earlier quoted context omitted.

This is almost certainly a different bug. I don't believe Go's standard library uses OpenSSL.

You’re right re: implementation —- I’m drawing a conclusion solely from the coordinated disclosure that it’s a similar crypto/TLS issue. If the Go issues were distinct I’d imagine they’d choose a different day to disclose/release?

it's unrelated; https://news.ycombinator.com/item?id=33382369

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

#86

Post by midasuni »

fulafel wrote: post #49
eastbound wrote: post #7

November 1st is a bank holiday in France, so a lot of sysadmins won’t be happy and systems will be vulnerable.

This is most likely but another possibility is that it was coordinated to happen on a bank holiday so systems can be dated with less impact from service outages.

In that case why not release about 0700UTC on a Saturday, pretty much everywhere has the weekend going either then or starting within a few hours

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

#87

Post by s-macke »

When I execute an ldd at /usr/bin/ssh I get

  libssl.so.10 => /lib64/libssl.so.10
  libssl3.so => /lib64/libssl3.so
  libnss3.so => /lib64/libnss3.so
What puzzles me is that I am using libssl.so.10 and libssl3.so at the same time. libssl3.so belongs to the nss package and not to the openssl package. Am I affected?

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

#89

Post by drran »

justinjlynn wrote: post #81
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.

That's a rather charitable interpretation of events. Events which didn't need to happen. Events which happened for dubious reasons and which depended dubious reasoning.

Demand your money back!

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

#90

Post by xorcist »

s-macke wrote: post #87

When I execute an ldd at /usr/bin/ssh I get libssl.so.10 => /lib64/libssl.so.10 libssl3.so => /lib64/libssl3.so libnss3.so => /lib64/libnss3.so What puzzles me is that I am using libssl.so.10 and libssl3.so at the same time. libssl3.so belongs to the nss package and not to the openssl package. Am I affected?

It is very unlikely that this affects OpenSSH regardless. Only the cryptographic primitives are used from OpenSSL, and none of the complexity of the SSL functions. The cryptographic functions themselves are small and extremely well tested.
Post reply on HN