3 ms·

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 donat

by nemo 13y ago

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.

peteretep 13y ago
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
- deleted 13y ago
  [deleted]
dllthomas 13y ago
Would it really have to be a fork? Working with the original team could be to everyone's benefit.
- clarry 13y ago
  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.
  - dllthomas 13y ago
    "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).
- nemo 13y ago
  Given the scale of reworking and reorganizing that would be involved, I assumed a fork would be the only viable approach.
  - dllthomas 13y ago
    I don't think the "fork or not-fork" has much to do with amount of reworking and reorganizing involved.
    - nemo 13y ago
      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.
      - dllthomas 13y ago
        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.
peterbotond 13y ago
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/ 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.
- deleted 13y ago
  [deleted]
- clarry 13y ago
  More like as of 15 years ago.

by nemo 13y ago

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.

peteretep 13y ago

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

deleted 13y ago
[deleted]

dllthomas 13y ago

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

clarry 13y ago
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.
- dllthomas 13y ago
  "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).
nemo 13y ago
Given the scale of reworking and reorganizing that would be involved, I assumed a fork would be the only viable approach.
- dllthomas 13y ago
  I don't think the "fork or not-fork" has much to do with amount of reworking and reorganizing involved.
  - nemo 13y ago
    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.
    - dllthomas 13y ago
      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.

peterbotond 13y ago

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/ 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.

deleted 13y ago
[deleted]
clarry 13y ago
More like as of 15 years ago.