On Tue, Sep 10, 2013 at 12:39 AM, Marijn Haverbeke <mari...@gmail.com> wrote: > The Rust team is aware of this possibility, and is guarding against it > by keeping a log of checksums and source git revisions for the various > versions of the compiler, so that compilers downloaded from the net > can be checked, and we could, if something dodgy is found, back-track > to a known trusted version of the compiler (or even all the way back > to the OCaml bootstrap compiler, though that'd be a lot of work). > > It is theoretically possible that someone manages to sneak in a commit > that adds an exploit to the compiler, but since patches are reviewed, > that is not terribly likely to succeed. Also, Rust is a small target > still, and it would be a marvelous feat of engineering to install a > functioning exploit in a compiler that is being overhauled and changed > all the time.
It's great that the team considers this and has a plan. This kind of attention to detail (including security detail) really attracts me to rust! Keep it up. There is a parallel issue around the security of builds. Doesn't it seem easier to hack into the server shipping rustc binaries then insert backdoors into those, rather than trying to "sneak patches" past many watchful code reviewers? Are rustc compilations deterministic? If not, can I humbly suggest a "soft goal" which is where devs do not switch tasks or priorities, but instead keep in the back of their mind potential sources for non-determinism in builds, as they modify rustc (or llvm)? The goal of deterministic builds is that given the same source snapshot on two different systems, and the "same version" of the build tools, the built artifacts are bytewise identical. I put "same version" in qualifying quotes because the two build tools installations may be compiled for different architectures, and they may be different versions, and they might even be different implementations if the entire compilation process is well-specified enough. Even with those differences in build tool installations, it's possible and desirable to generate bytewise identical build results (modulo all of the configuration such as target architecture). If N volunteers are using deterministic builds, they can cross-reference their builds and they can publish hashes which users can verify. Note, this is useful even if only a tiny fraction of users verify the distribution they've received, and more useful the more often more people do this verification. I'm out of my element here with the actual details, but I assume LLVM has a huge role to play here. Are there LLVM development discussions around deterministic builds? Some simple heuristics for noticing non-determinism are places where there's no defined ordering (for example, does the textual order of rust items map in a well defined way to the order of the linking symbol table?), places where time and random are used, places where local build system specific details are used (source path metadata, ...). If rust devs consider this important enough, it might be useful to talk to people at the Tor Project such as Mike Perry who introduces the need for deterministic builds here: https://blog.torproject.org/blog/deterministic-builds-part-one-cyberwar-and-global-compromise Regards, nejucomo > _______________________________________________ > Rust-dev mailing list > Rust-dev@mozilla.org > https://mail.mozilla.org/listinfo/rust-dev _______________________________________________ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
