Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

The only way to implement network-connected appliances safely is with open-source. It doesn't have to be under a permissive license, but it does have to allow the end user to change the code. Anything that is network-connected -HAS- to be update-able and independently verifiable. Anything less is a risk to all of us, like biologically unstable organisms released into a city would be.


I think issues like the heartbleed bug demonstrate that open source is not necessarily a credible defense against either incompetence or malice.


Ironically, I've been having the other side of this argument over on Diaspora: https://joindiaspora.com/posts/3918657

No, open source is not, in and of itself, sufficient.

I do believe increasingly, however, that it is necessary.

But so are other attributes: a healthy development culture, an approach which preemptively seeks out and eliminates security threats and holes, and most importantly, operates with the end-user as a primary focus. Projects with a strong record of this include OpenBSD (which is now conducting a focused effort to clean up the OpenSSL code: http://opensslrampage.org/) and the Debian project (with formal social contract, constitution, and policy all of which put the interests of the end-user front and center). While Debian's had its security snafus, particularly relative to OpenBSD, among Linux distros it's tended to be among the more secure and security-conscious distros, in my experience.

But projects with a long track record of disdain also tend to show themselves for want of strong security: PHP, awstats, GNOME, and more recently, systemd, all come to mind. I have grave concerns over the damage the latter is now in a position to do, and the fact that one dev has already been denied privileges to submit kernel patches by Linus Torvalds doesn't do much to increase my confidence.


Heartbleed was discovered and fixed.


Eventually, it was disclosed publicly and fixed, yes. But the standard set of arguments for open source and 'all bugs being shallow' would have expected it to be caught and fixed almost immediately.

I'm not arguing that open source isn't a better system, just that it's not a guarantee of safety when compared to closed source in this regard - both systems have to have competent people actually caring enough to pore over the code and provide fixes. Consumers cannot be expected to manually review and audit every line of code in their networked devices, nor (apparently) can they reliably depend on someone else to do it for them.


You can grab a firmware image from any closed-source appliance and immediately find dozens or hundreds of security problems that you know will never be fixed except possibly in your copy. They probably won't get fixed even if you talk to the manufacturer about them; in fact you run the risk of the manufacturer convincing the police to raid your home, or of the manufacturer suing you.

Now try the same with open-source software. There will be far fewer problems to find, because all of the obvious ones have been fixed already, and most of the difficult ones too. Even if you do find a problem, as soon as you put some information out there about it it'll be fixed. Upgrades invariably happen more quickly with open-source software, even in firmware roles, so the population is covered more quickly as well.

That's what is meant by 'given enough eyes'; not that all bugs are found and fixed immediately, but that all bugs are found and fixed eventually. OpenSSL simply didn't have enough eyes, for a variety of reasons. Developers in the US were discouraged from contributing, since our legal system has in the past been a risk to that kind of project. Many developers avoided it because they didn't know anything about old systems like VMS, or about cryptography. Most of the rest of us avoided it because it wasn't obviously broken.

Edit: We also generally assume that the NSA has 'enough eyes'. If they decide that they have to attack product X, then they get a bunch of people to look at product X and find its bugs. It doesn't matter whether it's open source or not, it's just a question of the number of eyes you apply to the problem.


Coverity and several other metrics seem to all conclude that over all, open source code is still more bug free than proprietary code.

http://www.zdnet.com/coverity-finds-open-source-software-qua...

If you seriously think that all bugs in open source are found and magically fixed immediately, I suspect you should try working as a community member / contributor of an open source software project.


>If you seriously think that all bugs in open source are found and magically fixed immediately

I don't think that at all. But, the heartbleed bug is an example of one which should have been, by all rights. It wasn't due to some complex crypto implementation, or an arcane syntactical edge case in C. It was a pointer bug. It was a simple, critical fault in a bit of software which had a lot of very qualified eyes on it, which a lot of people here would ridicule as a matter of course.

Now why, if something like that can happen with code most hackers and open source proponents care passionately about, should it be taken for granted that enough people are going to be validating dvd player and smart tv firmware for the end result to be better for the average end user than expecting whoever the manufacturer hires to do it?


It was a simple, critical fault in a bit of software which had a lot of very qualified eyes on it

Do we know this particular bit had had a lot of very qualified eyes on it? This is the problem with the eyeball theory. That a piece of code is open for anyone to read does not mean people who care actually read it. Everyone: it's open source, there are many of eyeballs on it, therefore I don't need to read it!

I'm trying to think of ways to make people wake up and routinely review the code and changes they use. You really don't need to be an expert programmer to spot a duplicated goto fail or the total lack of bounds checking.


Actually, per the actual OpenSSL maintainers, there are precious few eyes on the OpenSSL code.

http://www.theguardian.com/technology/2014/apr/11/heartbleed...

From Robin Segglelman, the maintainer who "accidentally" added the heartbleed bug:

""" ... OpenSSL is definitely under-resourced for its wide distribution. It has millions of users but only very few actually contribute to the project." """

I really think you should try joining and open source community and contributing some code. Then I suspect you'll understand that it is just as hard as any proprietary code (like that which I work on for $day_job). The difference is that Open Source code, even critical stuff that runs the internet, is often woefully understaffed and over expected to be perfect.


I stand corrected then.

>I really think you should try joining and open source community and contributing some code.

I have, not often though. Certainly not to anything critical.


Bad comparison. You can't compare code quality of open source versus enterprise C/C++ projects. You should compare against iOS, IIS, the CLR, etc...




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: