3 ms·

* Nah, the BSD guys are removing their dependency on OpenSSL, which is terribly broken for a number of reasons. They are not offering to replace OpenSSL for eve

* Nah, the BSD guys are removing their dependency on OpenSSL, which is terribly broken for a number of reasons. They are not offering to replace OpenSSL for everyone on every platform. That's not their goal. They've said this from the beginning. But not all is lost for you (the non-BSD guy complaining that BSD codes doesn't work outside BSD). Eventually the code will make it downstream. And they've dedicated a lot of thought to how to do that in a more secure manner than OpenSSL. Inspiring. * They kept the core functionality intact. Were you going to use heartbeats over TCP? Do you know even know what it is? How many of those on-by-default-workarounds were you using? Yeah they removed features. But for crypto code the lack of a rats nest is a feature. * They are maintaining compatibility with the old API for legacy code and developing a more sane API. Do you have something constructive to say about how an API might look for interop with your favorite flavor of software? Great! To the mailing list with you! * This was a tear down of code, not a reimplementation from scratch. But yeah, I agree. People should be looking over LibreSSL much more closely than OpenSSL. Sounds like that's something you would be interested in? ;) * It's open source? And there are discussions on the mailing list? What kind of public audit did you have in mind? * Don't really think hipster comments have much to do with LibreSSL's quality? * Can you point to evidence of the claim that not much has been changed in the last two months? Can you point to things you would have liked to see change? * No extra tests are needed, as they removed features. As features get added, yeah they're going to need to add some tests. * They don't exactly sit around in conference rooms and write reports for upper management. Have you checked out their mailing list? Aren't their packages signed and CVS transported over SSL? It's not like the code/packages are compromised. Otherwise, yeah I agree. It would be nice to have secure hateful hipster notes. ;). Kidding aside there's no reason not to add SSL. They should get on that. I'm thankful that someone is doing something about OpenSSL, which is a blight. I'm sorry I can't personally afford to do more to help. Criticality is a positive thing, especially with regard to crypto/security code. But aren't you being a little smidge cynical?

illumen 12y ago
The claim not much has changed can be substantiated by reading the article, and by looking in CVS. Modern code review tools provide public conversation of the code in question, and allow people to sign off on it. Is LibreSSL doing this? How can I trace a change or branch to a discussion (if there are even branches)? How are others supposed to easily look into their changes? They say this is a problem in the article we are talking about with their 12,000+ line diffs. What kind of audit? The traditional kind. Like the third party one the OpenSSL people are funding. Extra tests would be good if they are rewriting functions, which according to the article is what they did past month one. Is their test plan do a release and see what happens? I can't tell, since I can't see a test plan anywhere. If you're changing a function, and not doing so with even basic tests, and are holding your development practices up as 'best practice' you are lying. I'm being cynical because I care. They aren't doing many things the OpenSSL project themselves were taken to task for. As well, the OpenSSL project has now taken on many of the practices that LibreSSL are doing, but also they're doing much more (see their roadmap https://www.openssl.org/about/roadmap.html https://www.openssl.org/about/roadmap.html). To let LibreSSL get away with being careless is kind of silly when they are holding it up as being better.
- xnull2guest 12y ago
  Sounds like a whole lot of bikeshedding to me. Most of what you're suggesting doesn't apply, won't improve things, is a higher standard than we require of competing implementations or are being done already. It's fantastic you care though! I highly suggest you write some additional tests where you feel that there are test gaps or write a comprehensive test plan. I bet they'll happily accept test code/plans!

illumen 12y ago

The claim not much has changed can be substantiated by reading the article, and by looking in CVS. Modern code review tools provide public conversation of the code in question, and allow people to sign off on it. Is LibreSSL doing this? How can I trace a change or branch to a discussion (if there are even branches)? How are others supposed to easily look into their changes? They say this is a problem in the article we are talking about with their 12,000+ line diffs. What kind of audit? The traditional kind. Like the third party one the OpenSSL people are funding. Extra tests would be good if they are rewriting functions, which according to the article is what they did past month one. Is their test plan do a release and see what happens? I can't tell, since I can't see a test plan anywhere. If you're changing a function, and not doing so with even basic tests, and are holding your development practices up as 'best practice' you are lying. I'm being cynical because I care. They aren't doing many things the OpenSSL project themselves were taken to task for. As well, the OpenSSL project has now taken on many of the practices that LibreSSL are doing, but also they're doing much more (see their roadmap https://www.openssl.org/about/roadmap.html https://www.openssl.org/about/roadmap.html). To let LibreSSL get away with being careless is kind of silly when they are holding it up as being better.

xnull2guest 12y ago
Sounds like a whole lot of bikeshedding to me. Most of what you're suggesting doesn't apply, won't improve things, is a higher standard than we require of competing implementations or are being done already. It's fantastic you care though! I highly suggest you write some additional tests where you feel that there are test gaps or write a comprehensive test plan. I bet they'll happily accept test code/plans!