5 ms·

It is really difficult to refactor such things at the public API layer once they are widely adopted by 3rd party projects. Take the aforementioned error return

It is really difficult to refactor such things at the public API layer once they are widely adopted by 3rd party projects. Take the aforementioned error return inconsistencies -- how do you possibly deal with refactoring that for consistency when so many other projects are consuming OpenSSL as a library? You're trading one big problem (new clients are likely to get error return handling wrong) with another (if you modify all the returns for consistency, existing clients are now expecting the wrong return codes or, if you're smart and rename the functions to avoid that, at the very least the 3rd party consumers now need to do a lot of rewriting and deal with a painful crossover phase supporting both the old and new APIs).

derefr 13y ago
> how do you possibly deal with refactoring that for consistency when so many other projects are consuming OpenSSL as a library? You split your project into two components: 1. a new, clean, minimal core with a nice, shiny, new API; and 2. an "OpenSSL emulation layer" that loads your core library, and wraps it in OpenSSL-compatible cruft. It'd be very similar to, say, replacing Direct3D with OpenGL, and then writing a Direct3D emulation layer that calls OpenGL.
- stevehawk 13y ago
  it sounds so easy when you break it out like that but it is a considerable investment of time and money. Convincing people to spend either of those on refactoring vs adding new features is a constant battle. No one ever really understands it and typically responds with "you want to go back and do what you already did, just differently?"
  - astrodust 13y ago
    Projects like this where it needs urgent attention but it's so horrendously complicated and virtually impossible to get implemented correctly are very hard to commit to. You're going to be in for a world of hurt no matter what you do. Unless there's an actual federation behind the project that can fund it and keep it stocked with talent and oversight, something Mozilla or Apache could do, it will continue to be an unmitigated disaster.
    - stevehawk 13y ago
      Agreed. In fact, a lot of people are raging on OpenSSL and the OSS community not ever fixing this stuff but.. no one really raged on Apple over their SSL issue. They came out and showed the code and showed the missing curly brace and gave the "accidents happen" excuse but.. why wasn't that caught in unit testing? The only reason it wouldn't have been caught in unit testing is because Apple isn't unit testing their own SSL code. If Apple doesn't commit to doing security well why do people expect OSS to?
      - astrodust 13y ago
        It's because open-source software doesn't have a profit motive. It doesn't have an excuse not to. People did rage over Apple's SSL issue, but Apple handled it swiftly, pushing out updates to all affected devices as quickly as practical. It's also worth noting it was a validation bug, not something that could leech arbitrary bits of data from a device. I have no idea how some open-source projects get anything done, their development process is insane, but they manage to hobble along. Something as significant as OpenSSL needs to be held to a higher standard. If the OpenSSL team can't get their act together, it would be worth it if a larger non-profit organization took the initiative and made a tested, rock-solid implementation of same with an optional compatibility layer. I've had to integrate with OpenSSL before and the code in there is truly mad. Well written code should be boring and obvious, but OpenSSL is the polar opposite.
mcv 13y ago
> It is really difficult to refactor such things at the public API layer once they are widely adopted by 3rd party projects. But how did it ever get so widely adopted, if it's so hard to use? And even if it is widely adopted, that still shouldn't stop anyone from forking it and fixing all the problems.
- tinco 13y ago
  So why didn't you?
  - mcv 13y ago
    It's not something I work on. But clearly a lot of other people do. And I have some trouble believing that all those people building stuff on top of OpenSSL don't care about security. Look, if this was about something fairly inconsequential, like a library for a game or a blog or something, sure, use some badly maintained, badly documented, inconsistent library. But when you care enough about security to use SSL, surely you care enough to use something that's put together in such a way that you can be sure it does what you think it does? Bad documentation and inconsistent error handling in a security package sound like an unbelievably dangerous idea. And if it's really an unmaintainable mess, like everybody says, then how can bugs possibly be fixed? How easy would it be for the NSA to insert some crucial vulnerability into the code base? Security, moreso than anything else in computer science, needs to be clear, transparent, understandable, well documented and well maintained. If it's not, mistakes will be made and security will be compromised.
    - tinco 13y ago
      Why do you not include yourself in the list of people that work on it? Who are these other people that should be working on it? There's only 2 people on the OpenSSL team apparently.
- andyjohnson0 13y ago
  "But how did it ever get so widely adopted, if it's so hard to use?" Usefulness and lack of alternatives?

derefr 13y ago

> how do you possibly deal with refactoring that for consistency when so many other projects are consuming OpenSSL as a library? You split your project into two components: 1. a new, clean, minimal core with a nice, shiny, new API; and 2. an "OpenSSL emulation layer" that loads your core library, and wraps it in OpenSSL-compatible cruft. It'd be very similar to, say, replacing Direct3D with OpenGL, and then writing a Direct3D emulation layer that calls OpenGL.

stevehawk 13y ago
it sounds so easy when you break it out like that but it is a considerable investment of time and money. Convincing people to spend either of those on refactoring vs adding new features is a constant battle. No one ever really understands it and typically responds with "you want to go back and do what you already did, just differently?"
- astrodust 13y ago
  Projects like this where it needs urgent attention but it's so horrendously complicated and virtually impossible to get implemented correctly are very hard to commit to. You're going to be in for a world of hurt no matter what you do. Unless there's an actual federation behind the project that can fund it and keep it stocked with talent and oversight, something Mozilla or Apache could do, it will continue to be an unmitigated disaster.
  - stevehawk 13y ago
    Agreed. In fact, a lot of people are raging on OpenSSL and the OSS community not ever fixing this stuff but.. no one really raged on Apple over their SSL issue. They came out and showed the code and showed the missing curly brace and gave the "accidents happen" excuse but.. why wasn't that caught in unit testing? The only reason it wouldn't have been caught in unit testing is because Apple isn't unit testing their own SSL code. If Apple doesn't commit to doing security well why do people expect OSS to?
    - astrodust 13y ago
      It's because open-source software doesn't have a profit motive. It doesn't have an excuse not to. People did rage over Apple's SSL issue, but Apple handled it swiftly, pushing out updates to all affected devices as quickly as practical. It's also worth noting it was a validation bug, not something that could leech arbitrary bits of data from a device. I have no idea how some open-source projects get anything done, their development process is insane, but they manage to hobble along. Something as significant as OpenSSL needs to be held to a higher standard. If the OpenSSL team can't get their act together, it would be worth it if a larger non-profit organization took the initiative and made a tested, rock-solid implementation of same with an optional compatibility layer. I've had to integrate with OpenSSL before and the code in there is truly mad. Well written code should be boring and obvious, but OpenSSL is the polar opposite.

mcv 13y ago

> It is really difficult to refactor such things at the public API layer once they are widely adopted by 3rd party projects. But how did it ever get so widely adopted, if it's so hard to use? And even if it is widely adopted, that still shouldn't stop anyone from forking it and fixing all the problems.

tinco 13y ago
So why didn't you?
- mcv 13y ago
  It's not something I work on. But clearly a lot of other people do. And I have some trouble believing that all those people building stuff on top of OpenSSL don't care about security. Look, if this was about something fairly inconsequential, like a library for a game or a blog or something, sure, use some badly maintained, badly documented, inconsistent library. But when you care enough about security to use SSL, surely you care enough to use something that's put together in such a way that you can be sure it does what you think it does? Bad documentation and inconsistent error handling in a security package sound like an unbelievably dangerous idea. And if it's really an unmaintainable mess, like everybody says, then how can bugs possibly be fixed? How easy would it be for the NSA to insert some crucial vulnerability into the code base? Security, moreso than anything else in computer science, needs to be clear, transparent, understandable, well documented and well maintained. If it's not, mistakes will be made and security will be compromised.
  - tinco 13y ago
    Why do you not include yourself in the list of people that work on it? Who are these other people that should be working on it? There's only 2 people on the OpenSSL team apparently.
andyjohnson0 13y ago
"But how did it ever get so widely adopted, if it's so hard to use?" Usefulness and lack of alternatives?