181–190 of 232 posts
Earlier quoted context omitted.
They have new challenges with new packages. In the last 5 years there entered a lot of rust packages for example, a new compiler to tackle reproducibility with (and not trivial, even if upstream has worked on it a lot).
In my experience, rustc builds are reproducible if you build on the same path. They come out byte for byte identical.
Earlier quoted context omitted.
If the package maintainer's build pipeline is compromised (eg. Solarwinds), you are unlikely to be affected if you build from reviewed source yourself.
Except hardly anyone reviews a single line of code.
You are bringing up red herrings about trusted partners being malicious and untrustworthy.
Do you genuinely believe we should only solve a problem if it leads to a perfect outcome?
Earlier quoted context omitted.
Except hardly anyone reviews a single line of code.
So? We are trying to protect against a malicious interloper damaging the machine of a trusted and trustworthy partner. You are bringing up red herrings about trusted partners being malicious and untrustworthy. Do you genuinely believe we should only solve a problem if it leads to a perfect outcome?
So far exploits on FOSS kind of prove the point not everyone is using Gentoo, reading every line of code on their emerged packakges, let alone similar computing models.
Now if we are speaking about driving the whole industry to where security bugs, caused by using languages like C that cannot save us from code reviews unless done by ISO C language lawyers and compiler experts in UB optimizations, are heavily punished like construction companies are for a fallen bridge, then that would be interesting.
This really deserves more love. Who remembers Ken Thompson's "Reflections on Trusting Trust"? The norm today is auto-updating, pre-built software. This places a ton of trust in the publisher. Even for open-source, well-vetted software, we all collectively cross our fingers and hope that whoever is building these binaries and running the servers that disseminate them, is honest and good at security. So far this has mo…
I'm really surprised such an attack hasn't happened already. It seems so trivial for a determined attacker to take over an opensource project (plenty of very popular projects have just a single jaded maintainer).
The malicious compiler could inject an extra timed event into the main loop for the time the attack is scheduled to begin, but only if it's >3 hours away, which simply retrieves a URL and executes whatever is received.
Detecting this by chance is highly unlikely - because to find it, someone would have to have their clock set months ahead, be running the software for many days, and be monitoring the network.
That code is probably only a few hundred bytes, so it probably won't be noticed in any disassembly, and is only executed once, so probably won't show up in debugging sessions or cpu profiling.
It just baffles me that this hasn't been done already!
I don't see a single comment doubting the value of reproducibility, so I'll be the resident skeptic :) I think build reproducibility is a cargo cult. The website says reproducibility can reduce the risk of developers being threatened or bribed to backdoor their software, but that is just ridiculous. Developers have a perfect method for making their own software malicious: bugdoors. A bugdoor (bug + backdoor) is a del…
I think build reproducibility is a cargo cult. Most people here are debating you on the security angle, but in the case of Nix (and Guix) there is another important angle - reproducible builds make a content-addressed store possible. In Nix, the store is traditionally addressed by the hash of the derivation (the recipe that builds the package). For example, lr96h... in the path /nix/store/lr96h3dlny8aiba9p3rmxcxfda0i…
I'd guess that more than half of the invocations of gcc done by Make for example end up producing the exact same bit for bit output as some previous invocation.
Earlier quoted context omitted.
In my experience, rustc builds are reproducible if you build on the same path. They come out byte for byte identical.
Yeah I remember there was some drama regarding build machine path leaking into the release binaries
I mean it's worthwhile to fix, but that behaviour seems so standard.
This really deserves more love. Who remembers Ken Thompson's "Reflections on Trusting Trust"? The norm today is auto-updating, pre-built software. This places a ton of trust in the publisher. Even for open-source, well-vetted software, we all collectively cross our fingers and hope that whoever is building these binaries and running the servers that disseminate them, is honest and good at security. So far this has mo…
> and 6mo later every computer ... gets ransomwared. I'm really surprised such an attack hasn't happened already. It seems so trivial for a determined attacker to take over an opensource project (plenty of very popular projects have just a single jaded maintainer). The malicious compiler could inject an extra timed event into the main loop for the time the attack is scheduled to begin, but only if it's >3 hours away,…
Earlier quoted context omitted.
For some reason, many compilers and build scripts have traditionally been written in a way that's not referentially transparent (a pure function from input to output). Unnecessary information like the time of the build, absolute path names of sources and intermediate files, usernames and hostnames often would find their way into build outputs. Compiling the same source on different machines or at different times woul…
> The benefit of reproducible builds is that it's possible to verify that a distributed binary was definitely compiled from known source files and hasn't been tampered with, because you can recompile the program yourself and check that the result matches the binary distribution. It's not just security. If a hash of the input sources maps directly to a hash of the output binaries, then you can automatically cache buil…
Earlier quoted context omitted.
Yeah I remember there was some drama regarding build machine path leaking into the release binaries
Aha.. don't all compilers behave the same way, with debug info? I mean it's worthwhile to fix, but that behaviour seems so standard.
It is really, really annoying that the Rust team is not taking this problem seriously.
Earlier quoted context omitted.
Aha.. don't all compilers behave the same way, with debug info? I mean it's worthwhile to fix, but that behaviour seems so standard.
No, rust leaks the path to the source code on the build machine. This path likely does not even exist on the execution machine, so there's absolutely no good reason for this leakage. It is very nonstandard. It is really, really annoying that the Rust team is not taking this problem seriously.