Hacker News Reader

Comment by nemo | Hacker News Reader

I wish Theo and his colleagues would create a fork of OpenSSL that was up to OpenBSD/OpenSSH standards. It would be a huge level of work, but I'd happily donate to help fund it.

View on HN

Yes, yes a million times. Wonder if this will prompt them to. For a rewrite to have any traction, it would need implementing by a team with some credibility, and they're probably one of the few teams with that credibility

src/lib/libssl is in the openbsd tree as of 2 days ago approximately, and being trimmed as seen in commits: http://www.openbsd.org/cgi-bin/cvsweb/src/lib/libssl/

edit: precesion: libssl has seen a set of large commits, in the past 48 hours, and other libcrypto related changes.

More like as of 15 years ago.

Would it really have to be a fork? Working with the original team could be to everyone's benefit.

Some anecdotes from recent discussion suggest it's not so easy to work with the original team. Also, if their standard for quality is what it is, it might be hard for another project to start changing things.

"Some anecdotes from recent discussion suggest it's not so easy to work with the original team."

'k, certainly forking is better than letting poor quality persist, and it may be better than reimplementing from scratch. I just don't like resorting to it when unnecessary.

"Also, if their standard for quality is what it is, it might be hard for another project to start changing things."

Possibly, though their "standard for quality" is probably at least a little malleable (particularly right now).

Given the scale of reworking and reorganizing that would be involved, I assumed a fork would be the only viable approach.

I don't think the "fork or not-fork" has much to do with amount of reworking and reorganizing involved.

The scale of the project management involved would be tied to it, and that would take project buy in from the OpenSSL leadership far beyond anything I'd expect them to take, and also a much stricter leadership to keep things conformant to those higher standards. The current code base is mind bogglingly, shockingly bad, and the current leaders let that happen. Given Theo's leadership style on top of that I could only imagine a fork as even possible, he's slagged on the OpenSSL team already (justifiably).

I'd rather see a fork, honestly, to see more competent and disciplined standards and leadership, though that's a personal opinion. If the current project leaders stepped down and handed it off to people actually able to handle such an important software project, that'd be great, but I can't imagine it based on their past behavior.

Sure, I agree that it affects level of buy-in required, and that higher levels of buy-in are less likely. I don't think that it's clearly the dominant factor though - particularly in the face of an event like this, high levels of buy-in may very well be attainable. Maybe not, of course, but that would have more to do with intransigence on the part of the team - which would itself be the reason for the fork.

Reply on news.ycombinator.com