https://www.sifive.com/products/risc-v-core-ip/
Not quite ready for prime-time, but it's a big step in the right direction. At least there's hope for future.
My odds there are much better than they are trying to do a similar audit on MacOS.
> Can the person you hire do it?
There are people out there who are extraordinarily skilled at this sort of thing. Security flaws in, say, iOS are found regularly. That's how jailbreaks work. (And, BTW, the fact that Apple doesn't give me the option of opening up the jail on my own phone means that if I want this freedom I have no choice but to run some black-box binary from some unknown Chinese hackers. That is by far the biggest security risk I face when using Apple products and it is a direct result of their policies.)
> Would they have found the Heartbleed issue that was in open source code for at least two years?
They did find it, and I didn't even have to pay them. If I had paid someone to look, they might have found it sooner.
No system will ever be perfect. But I like my odds on Linux much better than on Apple.
Based on what metrics? Someone skilled in Assembly can and has found many vulnerabilities in closed source software. The chance of you as an individual being able to audit the entire Linux codebase and finding a new vulnerability are nil unless you have some special skills that you haven't mentioned that make you better than some of the top hackers and researchers.
There are people out there who are extraordinarily skilled at this sort of thing. Security flaws in, say, iOS are found regularly.
Despite the fact that is closed. How does that support your point that "open" software is easier to find vulnerabilities. You said that you could hire someone to audit the code, could you afford them?
That's how jailbreaks work
Without the code being open...
(And, BTW, the fact that Apple doesn't give me the option of opening up the jail on my own phone means that if I want this freedom I have no choice but to run some black-box binary from some unknown Chinese hackers. That is by far the biggest security risk I face when using Apple products and it is a direct result of their policies.)
Apple has the source code for all of the chips they use and they had a hand in designing most of them. As opposed to the random Android manufacturer who outsources their chips and the manufacturers give the OEMs binary blob drivers.
Even Google said they couldn't upgrade one of their devices because they couldn't get drivers for one of their chips.
Do you really run your Android phone with all open source software that you compiled and installed yourself? Including the various drivers? Have you audited all of it?
They did find it, and I didn't even have to pay them. If I had paid someone to look, they might have found it sooner.
And they've also found bugs in close Software and if you pay someone enough they could find stuff too.
No system will ever be perfect. But I like my odds on Linux much better than on Apple.
Based on what objective metrics?
Auditing C source code is orders of magnitude simpler, than auditing binary. With the same resources, you can have much more done in the former case than in the latter.
OpenSSL is also extremely arcane. I tried to work on it once, and spent days simply understanding the data structures. It was, when I was working with it, entirely undocumented. Out of those millions of eyeballs, say a few dozen completely understand the library, and a percentage of them have the capability to review the exact algorithms being implemented. Simply publishing source code is not a silver bullet to gain competent reviewers and contributors, otherwise Linux would be bug-free and have bug-free drivers for every device in existence.
Linus's Law has compelling arguments against it. esr may have been wrong about the bazaar.
There are people looking and finding security vulnerabilities in closed software. Why do you assume that it's any harder for a skilled assembly language coder to find vulnerabilities in closed source software. Heck back in the day I knew assembly language well enough to read and understand dissembled code and I wasn't that great at it.
Sorry, how would we be talking about it if they didn't find it?
How is that any better of a track record than vulnerabilities found in closed source code?
And the option is also open to you to be really good and find security vulnerabilities in closed source software just like the researchers at Google do and all of the people who found jailbreaks.
But even then, that wouldn't have helped with the latest bug found in x86 microcode...
Yes. Not necessarily with the knowledge I currently possess or with the effort I'm currently willing to put in, but if I wanted to put in the necessary effort and study, I could. Having that option open to me has value in and of itself even if I choose not to exercise it.
A complete layperson can use open-source software knowing that it has been looked at by at least some part of the community, conferring all kinds of security benefits.
But all of the people running Linux on x86 had no way of knowing that there was a bug in the x86 microcode.
By coming up with the same examples over and over again in lower threads you are coming close to trolling this thread and ought to stop and come up with a better argument for why a corporate system-on-a-chip system is inherently just as safe as hardware developed with open source firmware.
How has all of the "openness" of the Android ecosystem helped customers get patches for security vulnerabilities compared to iOS users?
And no one has pointed to a real world metric showing open source software being less vulnerable and getting patches faster than closed software.
And that one poorly maintained library was the basis of a mass industry wide security problem. It wasn't some obscure backwater piece of code.
Suggesting that "the community will find bugs, because eyeballs" is wishful hand-wavey exceptionalism that has been disproven over and over.
It's an unprofessional and unrealistic belief system that has no chance at all of creating truly secure systems.
Again, heartbleed is a terrible example because many many people have complained for a long time about the cruft building around OpenSSL. Do you think i don't read the code of an open source python module before I roll it into a project? Would I ever consider including a python module in my code that came to me as a binary blob (not that this possible ... yet)? Not on your life.
The reality is it's shitty that I have to trust corporations with closed source firmware and I wish it were otherwise.
If that's true, there should be a way that you can compare the amount of security vulnerabilities in iOS vs Android and the time it takes to get it patched and get the pst h distributed.
It should also be possible to have the same metric in Windows vs Linux, the various open source databases vs the closed source databases etc.
On the other hand there is an existence proof that closed source software doesn't prevent smart people from finding security vulnerabilities in closed source software - the number of vulnerabilities that researchers have found in iOS.
But why is everyone acting as if reading assembly code is some sort of black magic that only a few anointed people can do?
And if open source, easily readable code was such a panacea, the WordPress vulnerability of the week wouldnt exist.