Story happens in imaginary universe, but I'm using current time "relativation".

vmWare Player type of application (but for free). I consider adding it to Open Source because everybody is saying how great it is and how fast bugs can be fixed.

There's couple stories to be told:

Side of Manager
I like the fact that everybody can contribute to our project, in order to improve it by using suggestions and trustworthy community. Therefore I posted it on GitHub.

Side of Hobbist
Hey, we're community of 10.000 active programmers. We do our jobs really well. We love this project, so we try to look at files and improve their functionality, performance and security. We find about 5 hours a week each to improve the project.

Side of Haters/Crackers
Hey, we're little group of 100 software crackers. We do our jobs as great as hobbists supporting this project. This project totally pissed us off. So we go on GitHub, analyze the code and decide on how we can strike. We download the legitimate code and change client/server handlers (to allow Heartbleed), that "owners" and contributors don't get to patch, and we use the breach to steal wanted data. And we get past this issue with a year, continuously stealing people's data and it finally gets patched. We find about 70 hours a week each to seek vulnerabilities.

The Realism
So posting a non-profit project on GitHub or any alike site really that good move? It feels like posting your project on OS site makes it a Russian Roulette. Either you're going to be fast enough to find and patch vulnerability and get yourself good position in "Safe Software" lounge, or cracker are going to crack it easier, steal people's data and people will start disregarding software as unsafe.

Even worse for "managers" of software who will feel almost heartbroken when they want to create great usable and safe software to clients, while it turns out it's just a mine waiting to explode in your face.

I recently started contribution to a software on GitHub (oh boy, better run). And it would feel great to create at least project and find 30 people who like it as much as I do, to scan this code 30 times and make sure it can run at it's best and safest. But on the other side there's always malicious people. Are there any arguments you can throw against this statement? The idea is great, but realism (in my sight) makes it really bad.

Recommended Answers

All 8 Replies

When proprietary software is hacked, you are SOL in terms of fixing it since you do not have access to the source code. FOSS is not such, and since you can access the source code, you can analyze and fix it as necessary. So, in relative terms, Open Source software is MUCH more secure than proprietary code. I do not run proprietary code any longer. No malware on my Linux systems!

When proprietary software is hacked, you are SOL in terms of fixing it since you do not have access to the source code.

But I do...

If I, the owner of program have no access to source-code, who has?

If I notice bugs I repair them, so does community.
But it's way easier to break a code that you have access to, then wildly guessing where the vulnerability may be.

commented: If it is your program, that you wrote, then you can fix it. If you provide the code to the community, then it is in some sense "open source". -3

or cracker are going to crack it easier, steal people's data and people will start disregarding software as unsafe.

Here's my take on it: insecure software will be insecure regardless of code availability. Open source certainly makes insecure software easier to crack, but the underlying problem isn't being open source, it's being insecure.

The fix is not to implement security by obscurity and hope crackers aren't smart enough to dig into the binaries, the fix is to correct security holes. And for that goal, open source is potentially superior as there can be more eyes on the code.

Spot on from Deceptikon, in my never humble opinion.

Definitely a good argument from Deceptikon. thumbs up

However:

The fix is not to implement security by obscurity and hope crackers aren't smart enough to dig into the binaries, the fix is to correct security holes. And for that goal, open source is potentially superior as there can be more eyes on the code.

Yes, but there's also many crackers who can easily access the code. They don't need to be smart enough to dig into binaries anymore, they can just look at the source-code and find something. recompile, use it and voila. There's still that "counterhold" to this.

commented: True, but this is where signing the binaries is critical, otherwise you can't tell that the code has been altered! +0

Most open-sourced binaries and sources have been digitally signed with md5, or preferably sha-256 signatures, making it difficult for malware writers to create alternative versions of this code. This is not a perfect solution (no such exists in my opinion), but it does move the bar much higher.

I am glad deceptikon touched on security through obscurity. While reading through a crypto book I heard about the concept as well. As it is described in the crypto book, no crypography should rely on the algorithim being secret, but instead it should rely on the keys being secret, and the algorithim being robust (no flaws). When it comes to source code, eventually the binary will be reversed, and the processes will become clearer to hackers who are analyzing the algorithim regaurdless of access to the source code. You can make it harder by not releasing source code, but it is really just an obscurity thing, where somebody really accomplished at reversing wouldn't be phased much at all. So my take on it is that the more people you have contributing to the bug fixes, the more secure your source code will be. Safety in numbers. On the other hand making money often requires souce code remain confidential. For me, whether software is proprietary or not is less about security, and more about other factors.

If it is your program, that you wrote, then you can fix it. If you provide the code to the community, then it is in some sense "open source".

Nevermind, you misunderstood what I asked.

True, but this is where signing the binaries is critical, otherwise you can't tell that the code has been altered!

But cracker couldn't give two nuts whether his UAC would show no binary signed certificate UAC or binary signed certificate UAC. My point wasn't that the code should be verified. My point... sigh... nevermind... it all goes loose. The answer goes in another way than the question :(

Be a part of the DaniWeb community

We're a friendly, industry-focused community of developers, IT pros, digital marketers, and technology enthusiasts meeting, networking, learning, and sharing knowledge.