101–110 of 217 posts
This is supposedly the commit which fixes the bug https://github.com/openssl/openssl/commit/3df6aed7826640d944...
This is basically useless without identifying the vulnerability.
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…
Security flaws can be exploited by governments and corporations, too.
The same security flaw that lets you jailbreak a phone could also allow a hostile entity to say "we don't need you to unlock your phone/laptop, we'll just seize it and break into it using known security vulnerabilities".
Buy devices that you control. Don't try to make other people's devices less secure because you want to break into your own.
Earlier quoted context omitted.
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.
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…
Earlier quoted context omitted.
The track record of OpenSSL = memory management vulnerabilities. Vulnerabilities that are preventable. Google: openssl "use-after-free" site:cvedetails.com/cve It's time to accept that C is not the tool for the job. Good programmers still make mistakes and now we have tools to catch most of those mistakes. In Rust many of those errors become compile-time errors.
That's one possible reading of the situation, certainly. Another, however, is that openssl is uniquely poor quite separately from the language it happens to be implemented in. Unfortunately TLS libraries are thin enough on the ground that we can't really pick out patterns. It's like saying that microkernels are bad because HURD has serious issues; it could be true, but comparing by the well-known problem child isn't…
C is inherently bug-prone. Time to declare it unsafe at any speed.
This is basically useless without identifying the vulnerability.
It's not useless, and if it identified the vulnerability it'd massively increase the risk of it being used before patch release.
This is supposedly the commit which fixes the bug https://github.com/openssl/openssl/commit/3df6aed7826640d944...
I have done security releases before (not in OpenSSL), and the first line we have there is that don't push upstream in the flashiest text possible. In OpenSSL's case, they might share it with other major OSs beforehand (because many software statically link to OpenSSL), but there is always a secure channel in place to make sure the patches/commits are not leaked.
In the unfortunate event that the commits were pushed to a public repository, the most sensible thing to do is to just release the tagged release with the security announcement anyway.
Earlier quoted context omitted.
Speaking of go, it looks they will be patching this as well. https://groups.google.com/g/golang-announce/c/dRtDK7WS78g
Yep, this is interesting, I wonder what we can deduce about the nature of the bug from the fact that 2 separate implementations, one that's mostly memory safe, are impacted. (Of course Go didn't announce it's about the same thing, so it might be random, or might be some security research that found different bugs) Might it be a crypto bug, or logic bug (eg in x.509)? Is there code that's used by both OpenSSL and Go (…