Live data from Hacker News

"OpenSSL has exploit mitigation countermeasures to make sure it's exploitable"

article.gmane.org

241–245 of 245 posts

Re: "OpenSSL has exploit mitigation countermeasures to make sure it's exploitable"

#241
post #141

Earlier quoted context omitted.

I would actually be interested in hearing some of the issues related to LPGL in video games and other projects. Are there stories / write ups on this that you could link to or would you mind explaining it some?

I'm not aware of any long form text on this, but the issue is relatively straightforward. A publisher hires a studio to make a game, which then gets published on platforms that actively prevent users from (compiling and) running their own software (consoles, iOS). Since the user is not provided with the tools to replace a library used in a game, the terms of the LGPL cannot be met even if the studio were to release t…

I believe that GnuTLS is under LGPLv2 though.

Re: "OpenSSL has exploit mitigation countermeasures to make sure it's exploitable"

#242
post #121

Earlier quoted context omitted.

We need to stop have such a fucking accepting attitude about sloppy engineering in security-critical code. People who don't want to be held to a high standard should get out of there and go do something that can't break the internet.

I'm not saying we should accept sloppy engineering in security-critical code, I'm saying that it's pointless to insult people who contribute to free open source projects from the outside. We want to incite more people to audit and contribute to these projects, not the other way around. Insult the engineering, not the engineers. Or, alternatively, don't insult and propose improvements.

I didn't see it as an insult. I would react against personal insults as well, that's wholly unnecessary. Saying that a project is not cautious enough is not an insult, if it would be, we couldn't talk about quality at all.

Re: "OpenSSL has exploit mitigation countermeasures to make sure it's exploitable"

#243

Earlier quoted context omitted.

sqlite does not seem less mission critical to me, and definitely relied on funding: "D. Richard Hipp designed SQLite in the spring of 2000 while working for General Dynamics on contract with the United States Navy.[7] Hipp was designing software used on board guided missile destroyers" -- http://en.wikipedia.org/wiki/Sqlite#History

I work for a very large company that relies on a fork (with contributions back upstream) of SQLite for a majority of its massive enterprise SOA. It is not just unpaid volunteers keeping that project going.

What do you consider when choosing SQLite issues to assigns resources? I would guess it would start with issues relevant to your roadmap. If that's the case with most enterprise FOSS contributors, they most likely trusted the features of OpenSSL they were using. Thus no reason to go poking around that section of the code. It's understandable why a team might choose to not perform an ad-hoc security audit of features that pass specs, even more so when such an audit requires niche expertise. We can hope this bug changes that attitude and more enterprises with the resources and knowledge start performing security and encryption audits. Just as your buildings have security guards, we need proactive and preemptive audits of at least the most common libraries is use, flagging of software that implement unaudited encryption libraries. A Travis CI like badge on GitHub for these audit metrics would bring attention to the problem. We could call it EncryptCI. Maybe this already exists?

Re: "OpenSSL has exploit mitigation countermeasures to make sure it's exploitable"

#244
post #225

Earlier quoted context omitted.

I think now would be great time to reconsider the OpenBSD ipsec debacle in this kind of new light. Correct me if I'm wrong, but doesn't ssh use openssl libraries and the openbsd guys were heavily involved in openssl's development? A lot of people think the closed audit that found a minor unintentional bug was the last word on this subject, but the orginal guy who made the claim posted in 2012 further explaining how t…

openssl was not created by the same people behind openbsd.

You are correct, just got done reading Theo's rants on the subject and realized I was mistaken, so apologies. The same style of potential subversion may be at hand, regardless.

Re: "OpenSSL has exploit mitigation countermeasures to make sure it's exploitable"

#245

Earlier quoted context omitted.

I don't understand the point you are making with the filesystem. LOC as a single point of reference is useless.

10kLOC of Haskell for a filesystem seems like an awful lot, especially when considering how much more concise and higher-level Haskell is supposed to be compared to languages like C. Maybe filesystem code just don't fit too well into the functional paradigm?

That number was an upper bound estimate obtained by visually integrating the commit history, it is entirely possible that it is significantly lower.
Post reply on HN