5 ms·

It is explained in the design document: https://docs.google.com/document/d/1P3BLR31VA8cvLJLfMibSuTdwTuF7WWLux71CYD0eeD8/edit https://docs.google.com/document/d/

by yiyus 12y ago

It is explained in the design document: https://docs.google.com/document/d/1P3BLR31VA8cvLJLfMibSuTdwTuF7WWLux71CYD0eeD8/edit https://docs.google.com/document/d/1P3BLR31VA8cvLJLfMibSuTdw... Basically, you start from the last C version, and every version is supposed to be able to compile the next one.

justincormack 12y ago
Ah ok, so there will be a pretty long chain from 1.2 eventually, but hopefully it will be part of the test suite...
- jlouis 12y ago
  Usually you don't keep the chain. You just keep a working compiler. You can also bootstrap from another implementation of the language, e.g., gccgo. A common trick is to keep a highly portable interpreted version of the target language and then use this for bootstrapping, but often you attack new architectures by cross-compilation instead. It all depends. Also, it is common for self-hosting languages to require themselves to build.
- enneff 12y ago
  You should always be able to build a Go 1.x compiler with just the 1.4 tool chain binaries. We have committed to sticking to the Go 1.4 language and libraries for the compiler tool chain.
  - TheLoneWolfling 12y ago
    Where is this fact documented? Are patches tested against 1.4 tool chain binaries?
    - madhusudancs 12y ago
      Here https://docs.google.com/document/d/1OaatvGhEAq7VseQ9kkavxKNAfepWy2yhPUBs96FGV28/edit https://docs.google.com/document/d/1OaatvGhEAq7VseQ9kkavxKNA... In the proposal section.
    - enneff 12y ago
      > Where is this fact documented? http://tip.golang.org/doc/install/source#go14 http://tip.golang.org/doc/install/source#go14 > Are patches tested against 1.4 tool chain binaries? The builders build the tool chain with Go 1.4, so the build dashboard will show failures if a patch incompatible with 1.4 is submitted. (We have pre-commit trybots that do the same.)
cperciva 12y ago
So if you want to avoid trusting trust, you need to audit not only a C compiler and the source code for the Go compiler you plan on using, but also every past Go compiler as well?
- f2f 12y ago
  You can't avoid trusting trust. "Ken was here" :)
  - sanxiyn 12y ago
    You actually can. Proof here: http://www.dwheeler.com/trusting-trust/ http://www.dwheeler.com/trusting-trust/
    - f2f 12y ago
      I was alluding to Ken being the author of the old, as well as one of the authors of the new compiler. In jest :)
  - cperciva 12y ago
    You can. You just have to bootstrap all the way up.
    - deleted 12y ago
      [deleted]
    - fugyk 12y ago
      What if any intermediate version is found to contain the violation of trusting trust? Every go maintainer has to build every version sequentially from that version to current version.
- sesutton 12y ago
  You could audit the Go source and then use the diverse double compiling technique[0] to verify that the binary you're using corresponds to that source code. [0] http://www.dwheeler.com/trusting-trust/dissertation/html/wheeler-trusting-trust-ddc.html http://www.dwheeler.com/trusting-trust/dissertation/html/whe...

by yiyus 12y ago

justincormack 12y ago

Ah ok, so there will be a pretty long chain from 1.2 eventually, but hopefully it will be part of the test suite...

jlouis 12y ago
Usually you don't keep the chain. You just keep a working compiler. You can also bootstrap from another implementation of the language, e.g., gccgo. A common trick is to keep a highly portable interpreted version of the target language and then use this for bootstrapping, but often you attack new architectures by cross-compilation instead. It all depends. Also, it is common for self-hosting languages to require themselves to build.
enneff 12y ago
You should always be able to build a Go 1.x compiler with just the 1.4 tool chain binaries. We have committed to sticking to the Go 1.4 language and libraries for the compiler tool chain.
- TheLoneWolfling 12y ago
  Where is this fact documented? Are patches tested against 1.4 tool chain binaries?
  - madhusudancs 12y ago
    Here https://docs.google.com/document/d/1OaatvGhEAq7VseQ9kkavxKNAfepWy2yhPUBs96FGV28/edit https://docs.google.com/document/d/1OaatvGhEAq7VseQ9kkavxKNA... In the proposal section.
  - enneff 12y ago
    > Where is this fact documented? http://tip.golang.org/doc/install/source#go14 http://tip.golang.org/doc/install/source#go14 > Are patches tested against 1.4 tool chain binaries? The builders build the tool chain with Go 1.4, so the build dashboard will show failures if a patch incompatible with 1.4 is submitted. (We have pre-commit trybots that do the same.)

cperciva 12y ago

So if you want to avoid trusting trust, you need to audit not only a C compiler and the source code for the Go compiler you plan on using, but also every past Go compiler as well?

f2f 12y ago
You can't avoid trusting trust. "Ken was here" :)
- sanxiyn 12y ago
  You actually can. Proof here: http://www.dwheeler.com/trusting-trust/ http://www.dwheeler.com/trusting-trust/
  - f2f 12y ago
    I was alluding to Ken being the author of the old, as well as one of the authors of the new compiler. In jest :)
- cperciva 12y ago
  You can. You just have to bootstrap all the way up.
  - deleted 12y ago
    [deleted]
  - fugyk 12y ago
    What if any intermediate version is found to contain the violation of trusting trust? Every go maintainer has to build every version sequentially from that version to current version.
sesutton 12y ago
You could audit the Go source and then use the diverse double compiling technique[0] to verify that the binary you're using corresponds to that source code. [0] http://www.dwheeler.com/trusting-trust/dissertation/html/wheeler-trusting-trust-ddc.html http://www.dwheeler.com/trusting-trust/dissertation/html/whe...