Live data from Hacker News

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

globalsign.com

191–200 of 217 posts

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

#191

Earlier quoted context omitted.

I don't think the post is inaccurate or the authors untrustworthy, but I don't think it's a good idea to rely on their blog to get OpenSSL alerts, especially when there is an official, high signal-to-noise, alternative. If someone reads this HN submission and wants to make sure they get alerted about the next critical vulnerability, they should subscribe.

It’s not practical to subscribe to security feeds for every OSS project. Keeping in touch with the tech community is a valid alternative, in combination with patching best practice.

It's not wise to subscribe to none.

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

#192

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

People don’t work “On Call” any more? That’s news to me.

companies that abuse on call duty for planned maintenance suck. If it's something predictable or plannable, it's not on call. Hire people to work that day.

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

#193

Earlier quoted context omitted.

I’m curious if someone is going to come forward with it diffed out anyways…

I went through that process when I first heard the announcement. The fixes have been applied to master which is tagged for a release. You can search issues by severity tag and it becomes pretty obvious which of the few issues is related to the problem (one of the contributors flat out stats a change must be merged for a major security fix). Went looking at PRs and came across a buffer overflow. I stopped at this poin…

This is a stupid question but is the patch not being released until Nov 1, or is the security patch already in the Ubuntu updates and they're just not publicly releasing the vuln until Nov 1?

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

#194

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.

Note that the ring maintainer has long since stopped yanking releases. More importantly, it seems ring has recently hit a long dry spell of getting no new commits at all. There has been some light maintenance work recently, but outside contributions haven't had a credible path into the main branch for a long while now.

The the old yanking policy was extra work I did with the intent to help people. It was unfortunate that Cargo had that bug, but also I should have been much more diplomatic in how I dealt with it.

I've just returned from a long break and I do have a concrete plan to catch up on the backlog. I have concrete plans for making it easier for people to get their PRs merged, making ring portable to all platforms, and eliminating all the remaining bits of C code in the next two quarters.

Feel free to reach out privately if you want to talk: brian@briansmith.org.

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

#195

Earlier quoted context omitted.

It seems unlikely to me that the maintainers are that careless.

It is the norm for the patch to be committed and the CVE to be acquired as part of that process.

Yep, per this comment my optimism was misplaced.

https://news.ycombinator.com/item?id=33384596

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

#198
post #171

Earlier quoted context omitted.

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…

> Think Java: for each type you have to create a new file. That's untrue, Java has inner classes, and they can even be public. A "public static" inner class is nearly indistinguishable from a normal top-level class (the only real difference is that its name in the bytecode has a $ character separating the names, that is, its name in the bytecode ends up being something like "org.example.Outer$Inner").

Well, you still have to define them inside of another class then and have to find one that makes sense. They also have an reference to the outer class which might not be desirable.

That being said, it maybe makes it slightly better, but I hope you agree that this is still very much a supoptimal solution and probably comes from a time where searching filenames was the best way to navigate code in the lack of modern IDEs.

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

#199
post #63

Earlier quoted context omitted.

Software inhibiting user freedom (like drm) often gets broken using buffer overflows, string parsing mistakes, ... (as seen on many game consoles). Broken (drm) software allows for more user-freedom. If this software was using Rust, it would be much harder to break them than is currently the case. And tbh, I have to concur (somewhat). I have lost little-to-nothing due to software exploits, but have gained significant…

The idiom for this is “biting your nose off to spite your face.” You should do good things consistently, not bad things to offset worse things. If DRM is a serious problem in your life, put your money and time where your opinions are and avoid hardware and software products that enforce it rather than mandating insecurity for everyone else.

It's impossible to get AAA games (and most AA games) without some form of DRM (with some notable exceptions), the same as high(er) budget media productions.

The Kindle was already 8 years old when I got it, isn't it better to re-use it with more current software? The same with router hardware that gets exploited to flash OpenWRT.

It's very hard to get a modern Smartphone (with acceptable cameras, battery life, performance and software availability) with manufacturer-intended root access.

While I agree that people should adopt Rust (and other approaches) for their security porperties, it's not hard to see how it may lead to exploits getting rarer and to more categories of devices & content that can't be reasonably used in a "free" way, even if not intended by the manufacturer. Thus making it much harder to have control over the devices you own (without becoming some kind of luddite).

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

#200

Earlier quoted context omitted.

It is the norm for the patch to be committed and the CVE to be acquired as part of that process.

Yep, per this comment my optimism was misplaced. https://news.ycombinator.com/item?id=33384596

Or, it appears I may have been correct the first time.

https://news.ycombinator.com/item?id=33382684

Post reply on HN