November 1st is a bank holiday in France, so a lot of sysadmins won’t be happy and systems will be vulnerable.
Also an election day in Israel, which is a bank holiday.
Patch OpenSSL on November 1 to avoid “critical” security vulnerability
121–130 of 217 posts
Re: Patch OpenSSL on November 1 to avoid “critical” security vulnerability
#122Ubuntu 22.04 & RHEL 9 are the major distros impacted. Docker images built on ubuntu:latest will also be impacted. The latest releases of Alpine/Debian/AL2 are all not impacted, they use 1.1.x lineage.
What if you're using using the 1.0.x lineage? Does this vulnerability specifically impact you? ducks and covers
Re: Patch OpenSSL on November 1 to avoid “critical” security vulnerability
#123What's the 'best' way to find out if there are binaries in which libssl is statically linked?
Search the binaries for strings/messages that are unique to libssl. It's the only way (and it still doesn't give a conclusive answer) if the provenance of the binary is unknown.
Re: Patch OpenSSL on November 1 to avoid “critical” security vulnerability
#124Earlier 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…
[deleted]
Re: Patch OpenSSL on November 1 to avoid “critical” security vulnerability
#125Earlier quoted context omitted.
Demand your money back!
Oh no. Just because they donate their time and effort the community can't criticise them; even if how they work and interact with the community hurts and embarrasses the community... it was all free after all and the community added nothing to it! /s That's really not how it works when you work with others and use other's resources and time. Nobody's entitled to their effort, but they're also not immune to criticism…
Then stop using ring? It just sounds like you want to have your cake and eat it too.
Re: Patch OpenSSL on November 1 to avoid “critical” security vulnerability
#126Earlier 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.
Indeed - this is one of the positives of Go, as all the dependencies get linked statically, giving nice portable "single binary" solutions. Grepping function names seems a reasonable approach, as long as you're not trying to detect something that is obfuscating its use of libssl (i.e. by mangling strings together). It appears if you strip a binary, any definitive information about the libraries linked in statically i…
Unsure why people keep referring to static linking as a positive in this thread? Downstream consumers of statically-linked binaries have no practical way to scan their systems for known-vulnerable versions of libraries, that seems a profoundly negative consequence to me.
Re: Patch OpenSSL on November 1 to avoid “critical” security vulnerability
#127How many times does this have to happen before we start rejecting components written in unsafe languages?
Until we finally get liability widespread across the industry and not only in domains where human lives are at risk, just like in every other industry.
When the pocket money gets affected all companies will care about security.
Things are thankfully moving into that direction, US security bill already calls out that one needs to think about delivering software written in C and C++. Only a matter of time until one needs some kind of clearance to deliver software to government agencies with unsafe languages.
Re: Patch OpenSSL on November 1 to avoid “critical” security vulnerability
#128Earlier 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…
Well, Go isn't really a great language for safety either. Memory safety maybe yes, but not in general. Rust or Zig do much better here.
Rust yes, Zig is hardly any better than Modula-2.
Re: Patch OpenSSL on November 1 to avoid “critical” security vulnerability
#129Earlier quoted context omitted.
They don't have GC so they either make programs difficult to write (Rust) which hinders delivering secure replacements, or have use-after-free security problems (Zig) [1]. Use a GC when you can, it's the biggest programming productivity and quality improvement in PLT of the last 60+ years. [1] Though I know Zig has some interesting mitigations, some used and some under research: https://news.ycombinator.com/item?id=3…
Modern automatic memory management techniques like RAII and ARC largely render GC obsolete.
Reference counting is hardly modern, and is a GC algorithm.
Re: Patch OpenSSL on November 1 to avoid “critical” security vulnerability
#130Earlier quoted context omitted.
What makes Zig safer than Go, to your mind?
Features such as sum types (enums) that you can pattern match on. Or generics (well now Go got them as well, for a reason). Maybe it doesn't immediately sound as if this is related to security, but it is. If it is hard to model your data and hard to work with it, then people will go the "easy and fast" path. Think Java: for each type you have to create a new file. Even with modern tooling that is still annoying. So p…
No you don't, only for public types , types internal to the package can stay on the same file.