Slouching towards a cryptography monoculture

OP
J

Jose

Aspiring Daemon

Reaction score: 760
Messages: 899

Exactly! #me 2! Please do show me where I wrote THAT!
We're talking about Libressl, right?
Using modern protocols that bypass known vulnerabilities of previous approaches is also important, right?
If you're not referring to Libressl, then what is it that is preventing the adoption of the modern protocols?
 
OP
J

Jose

Aspiring Daemon

Reaction score: 760
Messages: 899

It's right there in the wiki link:
  • Fields can be changed without breaking binary compatibility
Not a security improvement.
  • Applications are more robust and can be more assured about correctness
Does not guarantee robustness or correctness in the library itself. Can maybe make it easier to write correct and robust applications that link with the library.
  • It helps determine which (new) accessors and settors, for example, are needed
Not a security improvement.
  • (Paraphrased from nabble) Prevent wacky nonstandard unproven hijinks with standard API calls. Please compile this yourself.
Not sure what this means at all. A link to the "hikjinks" in Nabble would've been nice.
Basically a function-call based API instead of one based on object attributes. Looks like they had a mix of the two and they just are cleaning up for the purposes of #2 in that list.
By all means change the curtains to fix the leaky windows. Fluffy interfaces have downsides too. One of the reasons removing the heartbleed "functionality" was so easy is that almost no one used it. It was a misfeature in search of a use case.
 

msplsh

Aspiring Daemon

Reaction score: 166
Messages: 504

Uh, it's called "code cleanup" or "refactoring", not "security improvements." I don't know anything about you, but for myself, as a programmer, doing these sorts of passes over an "API", especially one that just kind of "evolved" instead of being designed, is kind of normal. I don't know why you're seemingly demanding that the changes be strictly related to security improvements. Making getters and setters go through function calls make mocking easier so you can build tests against it and do things like put mutexes in to help with threading. What I'm saying is that this is all normal. Not a conspiracy.

I linked to the Nabble thing. Did you not read it? The complaints where that people couldn't hijack standard routines with their own custom experiments and have other apps link to their stuff unwittingly versus just recompiling. Not a very compelling argument when most of what you'd be linking is open source too.

Complaining that a code cleanup pass is "changing curtains" seems like just being combative. Have you heard of static analysis? This sort of change enables those kinds of auditing tools to work.

Heartbeat functionality is part of the DTLS RFC. OpenSSL didn't invent the "misfeature" out of whole cloth.

What do you even want here? Start a good old fashioned flamewar similar to Gnome vs KDE? LibreSSL is complaining they don't have the manpower to "keep up" with basic changes like this, which seems like there is literally not enough available crypto programmers to support two codebases. Why not just fork 1.1 again after OpenSSL did all the work and re-rip things out, since that's all they seem to be caring about.
 
OP
J

Jose

Aspiring Daemon

Reaction score: 760
Messages: 899

Uh, it's called "code cleanup" or "refactoring", not "security improvements." I don't know anything about you, but for myself, as a programmer, doing these sorts of passes over an "API", especially one that just kind of "evolved" instead of being designed, is kind of normal. I don't know why you're seemingly demanding that the changes be strictly related to security improvements. Making getters and setters go through function calls make mocking easier so you can build tests against it and do things like put mutexes in to help with threading. What I'm saying is that this is all normal. Not a conspiracy.
I agree that these are desirable, but I thought the reason these backwards-incompatible improvements were adopted was because they had to be for security reasons. I see no security justifications for them.

Yes, cleanup is important, but so is backwards compatibility, and especially so in a library that is so widely used. Why inflict the pain on your users for nice-to-have improvements? Wouldn't it have been more reasonable to introduce new APIs and leave the backwards-compatible ones alone in maintenance mode?

I linked to the Nabble thing. Did you not read it? The complaints where that people couldn't hijack standard routines with their own custom experiments and have other apps link to their stuff unwittingly versus just recompiling. Not a very compelling argument when most of what you'd be linking is open source too.
What I saw was actual cryptologists complaining that testing the crypto parts was becoming more difficult. This is not a compelling argument in favor of the API changes.
Complaining that a code cleanup pass is "changing curtains" seems like just being combative. Have you heard of static analysis? This sort of change enables those kinds of auditing tools to work.
Please explain how these changes are needed for static analysis.
Heartbeat functionality is part of the DTLS RFC. OpenSSL didn't invent the "misfeature" out of whole cloth.

What do you even want here? Start a good old fashioned flamewar similar to Gnome vs KDE? LibreSSL is complaining they don't have the manpower to "keep up" with basic changes like this, which seems like there is literally not enough available crypto programmers to support two codebases. Why not just fork 1.1 again after OpenSSL did all the work and re-rip things out, since that's all they seem to be caring about.
I've ignored any sort of meta-arguments about my motives or anyone else's. Those are just not productive. I will continue to ignore them with this one exception.
 

msplsh

Aspiring Daemon

Reaction score: 166
Messages: 504

I thought the reason these backwards-incompatible improvements were adopted was because they had to be for security reasons.
Ok, but that's not the case, so why make a fuss about it not exclusively being that way?

Why inflict the pain on your users for nice-to-have improvements?
Security benefits of static analysis? Easier to add new features? Nice to have means easier to audit? It's their codebase? They went out of their way to find the users this affected and created new functions for their purposes. Doesn't seem very malicious to me.

cryptologists complaining that testing the crypto parts was becoming more difficult
I saw "making it much harder to use the library with experimental or non-standard algorithms and methods" which is not the point of most OpenSSL deployments. Also, if they want to noodle around with it, they can just compile it themselves. It's not like it's "hidden" in the source, just the binary API.

Please explain how these changes are needed for static analysis.
Are you a programmer? If you aren't, then I'm not sure why you're arguing for them. They're moving things like manually setting structure data behind function calls to set the structure data. This lowers the variability of entry points for these things changing for security analysis, can provide validation against other variables at assignment time, prevent invalid initialization, etc.
 
Top