Clearly if you moved to OpenOpenSSL.org you would be better off!
Ask HN: Negative OpenSSL sentiments
31–40 of 52 posts
Re: Ask HN: Negative OpenSSL sentiments
#32You probably not the only one. I'll bet there are some who will defend this project no matter what happens.
But there are also people who have been annoyed with OpenSSL's needless complexity for many years. And they are speaking out too.
https://twitter.com/OpenSSLFact
The question is: Who are the ones more likely to drive us to a better solution than the status quo?
As other commenters have stated, the OpenSSL Project is not the only way to implement SSL. There are other open projects, though do not call themselves "OpenSSL".
I would imagine there is tremendous power over some peoples' minds when a project has the name "Open" and at least a small bit of history. They will defend it fervently without caring much about the code itself.
The OpenSSL Project's code is awful if for no other reason than it is far too complex to use, let alone when security is a requirement.
You can shift the focus to the programming language used or to "lack of funding" or whatever else you can conjure up, but the fact remains: OpenSSL's code is a mess.
Other SSL projects have implemented SSL in much simpler and smaller code. It makes one wonder how OpenSSL maintains its position as the default and we continue to accept the problems it creates.
Maybe because of attitudes like yours: "How dare anyone offer any critique on OpenSSL."
Re: Ask HN: Negative OpenSSL sentiments
#33There are obviously systemic problems, like funding, corporate (and government) under-investment of time and talent, and implementing an imperfect standard. Those have a significant impact, to be sure.
But bad code is bad code is bad code. And it doesn't take too much investigation of OpenSSL to realize it's not good code. To date the inertia of network effects has outweighed the badness of OpenSSL. Hopefully the Heartbleed fall-out will disrupt those network effects and get end-user developers to explore other implementations or spur renewed investment in improving OpenSSL. But it would be folly to continue on with the status quo.
The Spolsky argument is that you should never throw working code away. Part of the reason for doing so is that you will have subtle business logic embedded in the old code. However, in the case of SSL, there's a specified protocol. So, if there's a codebase to be rewritten from scratch, it's one that's an implementation of a spec.
Re: Ask HN: Negative OpenSSL sentiments
#34I've tried not to be too critical of the developers, but I do understand where some of the negativity comes from. Have you ever tried to use OpenSSL, as a developer? It's kind of a crufty mess. * Initialization is even more complicated than the security needs dictate, and so is everything afterward. * The internal abstractions are leaky, e.g. requiring a poll for read before you can write (and vice versa), because of…
OpenSSL is less like a library, and more like a framework. You need to mesh your code to it pretty closely to get anything done. All you want is a SHA256? Too bad, here's a dozen things you need to do first. A lot of what makes OpenSSL complicated is that it covers almost every crypto/algo/protocol permutation (there are lots) and it is heavily tuned to run fast on a variety of hardware. I like PolarSSL as an alterna…
PolarSSLs biggest problem seems to be GPL.
And all the people who favor bsd style license instead.
Weve seen it before, a license which appeals to those who would benefit from it but not required to provide something back to the community - such projects fare worse in the long term than GPL or GNU projects.
I think this mentality also explains why people hate on openssl - they expect something for nothing.
Its 2014 we should know better than to trust corporations will do the right thing and require any modifications be released back to community. They wont and they dont.
Re: Ask HN: Negative OpenSSL sentiments
#35Couldn't agree more. Heuristic to use when someone is bashing someone else's code: Have you contributed (money, code, docs) to the project? If the answer is no: person lacking skin in the game - irrelevant (even harmful) armchair comment.
I don't think that's very good reasoning. Bad software is bad software regardless of who has funded it, who has committed code to it, or who has written its documentation. One does not have to be a contributor to that software in order to analyze it and make a judgment regarding its quality.
Fork it. Nothing is stopping you.
Re: Ask HN: Negative OpenSSL sentiments
#36It's somewhat understandable; OpenSSL is a bit of a mess, and the two most recent occurrences have made me seriously think about learning more crypto in order to write a replacement, ala DJB (cf sendmail/qmail, bind/tinydns). Of course, while I think I wouldn't make any buffer overflow errors (I've got tools and training for that), I'm fairly certain I wouldn't get the crypto right the first time, and probably not the second either . . .
That being said, I too get annoyed at a few misguided POVs:
1) "Open source sucks!" - This bug would probably never been found, and even less likely would it have been fixed had OpenSSL been closed source.
2) "C sucks!" - OpenSSL would not be so widely used if it was written in another less portable, less efficient language, and besides, bad code can be written in any language.
Re: Ask HN: Negative OpenSSL sentiments
#37If anything I'm pissed at large companies relying on a piece of software that's barely funded.
Especially large networking gear whose business is dependent on it. I am less pissed at a website using OpenSSL. Funding from the hardware companies would probably have prevented this issue.
GPL with a commercial license solves this.
Even a not for gratis version of GPL would do.
Companies are wasting bucks left and right on stupid shit lie oracle or microsoft licenses when free software and gratis versions exist.
Its a problem in structure and values of society. Had all enterprises valued freedom the entire society and each company would be better off. But no.
Re: Ask HN: Negative OpenSSL sentiments
#38I've tried not to be too critical of the developers, but I do understand where some of the negativity comes from. Have you ever tried to use OpenSSL, as a developer? It's kind of a crufty mess. * Initialization is even more complicated than the security needs dictate, and so is everything afterward. * The internal abstractions are leaky, e.g. requiring a poll for read before you can write (and vice versa), because of…
Isn't documentation something that can be fixed by people as they use OpenSSL?
Re: Ask HN: Negative OpenSSL sentiments
#39It sounds to me like the way to solve this problem is to turn OpenSSL into a benevolent for profit company with an actual business model. Why not give the software away as is current practice but then charge top-dollar to MSFT, Google, et al. for professional consulting? This way they could actually devote real resources to the project and implement some of the obvious process reforms that OP and others are suggestin…
Not sure why you're getting downvoted; it's a legitimate question. I'm not sure OpenSSL is really a good match for that. I've never really studied this, but my impression is that open-source companies fall into two categories: 1) Very small consulting companies built around one or a few passionate people that scrape by rounding up contracts for specific features that businesses want, and 2) Larger companies that prov…
EU and most its memeber states intelligence agencies mission is to secure national infrastructure. Oh like the internet.
They already have tons of money thrown at them from taxes.
Its just that surveillence and monitoring of citizens and industrial espionage has higher priority than...their stated goal? Theyre too busy analysing malware and making their own, exploiting openssl for their benefit while keeping and hoping none othet agency knows their exploits.
Re: Ask HN: Negative OpenSSL sentiments
#40Operating systems are filled with bugs and complexity. Yet OpenBSD has had two remote holes in a heck of a long time. Everything you cite as being necessary, was within the authors power to do. Some TLS implementations are close to being formally verified as not having undefined behaviour. OpenSSL is nowhere near that state. There's no point in helping it out when better run projects could use the resources better.