Hacker News Reader

Hacker News

Comment by deknos | Hacker News Reader

Parent Full thread

deknos

> Just having access to the code is enough for audits, regardless of the license.

No. who guarantuees that the code is the one, which is compiled to the binary you are running?

View on HN

You can use Reproducible Builds to compile the source code and get the exact same binary:

https://reproducible-builds.org/

with opensource you can do this. but with closed source like from microsoft, that is not automatically given.

In the context of “government agencies”, they can just order Microsoft to make it possible, if they care.

In the case of Windows for Warships[0], one of the arguments (if they absolutely had to use Windows and nothing else) might be something like “Dear Mr. Gates, if you don’t empower us to do our job, we can’t guarantee that North Korea won’t retarget our nukes at your face. Sincerely, the Royal Navy.”

[0] https://en.wikipedia.org/wiki/Submarine_Command_System

You could have some sort of reproducible-builds escrow organisations; for eg release your code to them, they would do a build and publicly sign hashes of the build they produced.

Apologies for my ignorance here, but what is the current "market penetration" for reproducible builds? As in, if you combine all sources of FLOSS binaries, what percentage of total binaries follow use this system?

Looking at the site you linked, am I to correct that this is still early days in actual implementation?

There are lots of open source distros involved in the Reproducible Builds project and many of them are running CI to identify potential sources of non-determinism and identify regressions etc. For example currently 83.4% of Debian unstable amd64 is reproducible on the CI system (which builds twice in two different build environments and compares the builds). The variations tested for unstable are more than those for bookworm/bullseye though, so the numbers aren't easily comparable. Also, For Debian at least, there is some work on reproducing existing binaries from the archive using the Debian snapshot service, but I'm not sure where that is at.

https://reproducible-builds.org/who/projects/ https://reproducible-builds.org/citests/ https://tests.reproducible-builds.org/debian/reproducible.ht... https://tests.reproducible-builds.org/debian/index_variation...

Personally I find the Bootstrappable Builds project way more important and interesting. They are aiming to go from less than 1000 bytes of audited machine code (not assembly) plus all the necessary source code all the way to a full Linux distro. They are impressively far along already. They use multiple techniques for bootstrapping higher levels, including writing new implementations of languages written in other languages, using old versions of languages that were written in other languages etc. Some details here:

https://bootstrappable.org/ https://github.com/fosslinux/live-bootstrap/blob/master/part... https://github.com/oriansj/talk-notes/blob/master/live-boots...

Edit: some talks about bootstrappable:

https://github.com/oriansj/talk-notes/blob/master/talks.org

Okay, event you are assured that the source code you see are the origin of the binary you run, still no one can guarantee you there are no security concerns. The reason is simple: software are written by human, at best they were created with good will and there were due diligence. But doesn't matter how careful the developers and the auditors(if there were any) were, there are for sure security related bugs. Making it worse, there have been and going to have lots of deliberately planted backdoors. Given the complexity of the software and the cost of auditing, even if you have all the original source code, most likely you are unable to reveal planted backdoors. And if you indeed found something, how can you tell whether it was bug or a backdoor?

This part of the subthread was about ensuring the binary you run was built from the source code you have. Of course there could be bugs in that source code and or bugs in the resulting binary, so you have to audit both of them and fix anything suspicious.

There are engineering solutions to this, as another comment mentioned.

But, you don’t necessarily need an engineered solution to it, either. Trust can be established through non-engineered means.

trust can be established otherwise, but with software it is extremely hard to notice that trust violation for closed source software

If you're really that paranoid that you believe such conspiracy theories, then simply compile and run the source code they provide, and run that instead of the binary they also provide.

But you have to admit, it's a pretty implausible conspiracy theory, since it would be so straightforward for you to do that. Because they're literally providing you the source code WITHOUT the backdoors, which you believe they don't want you to compile and run.

how can i compile microsofts code? and there are easily systems which are so complex if you compile them the wrong way, you get other behaviour or more bugs.

and it may be also human error, not a conspiracy theory. if you do not have the source code and the recipe to build it yourself than you can not guarantuee that the inspected sourcecode (which was given to you either by disk or by a datablob over the internet) is the binary which you are currently running on your windows.

hell, perhaps they shipped an update which broke an security measure, and the update was shipped after you inspected the source.

Reply on news.ycombinator.com