4 ms·

Go 1.18 onwards will solve this problem: https://utcc.utoronto.ca/~cks/space/blog/programming/GoVersionOfYourSource https://utcc.utoronto.ca/~cks/space/blog/pro

Go 1.18 onwards will solve this problem: https://utcc.utoronto.ca/~cks/space/blog/programming/GoVersionOfYourSource https://utcc.utoronto.ca/~cks/space/blog/programming/GoVersi... > The go command now embeds version control information in binaries including the currently checked-out revision and a flag indicating whether edited or untracked files are present.... Additionally, the go command embeds information about the build including build and tool tags (set with -tags), compiler, assembler, and linker flags (like -gcflags), whether cgo was enabled, and if it was, the values of the cgo environment variables (like CGO_CFLAGS).

nefitty 5y ago
My list of languages to practice were Scala and Rust. Maybe I'll do Scala and Go considering this single point.
- ncmncm 5y ago
  In other words, you are not actually interested in programming.
xxgreg 5y ago
There's also ongoing work to build a dependency vulnerability database. This is proposed to be surfaced via a built in `go audit` command. https://go.googlesource.com/proposal/+/master/design/draft-vulndb.md https://go.googlesource.com/proposal/+/master/design/draft-v...
derefr 5y ago
On Windows, the Microsoft compilers and linkers have inserted such toolchain/library version metadata into PE executables for decades now (the "RICH" header — https://bytepointer.com/articles/the_microsoft_rich_header.htm https://bytepointer.com/articles/the_microsoft_rich_header.h...). At the time that Microsoft started doing it, paranoiacs thought it was some kind of anti-piracy software fingerprinting mechanism, embedding the compiling computer's MAC address or something. But really, it serves exactly the same purpose that Golang's effort does here: to let you map compiled-artifact back to inputs.
pabs3 5y ago
So if you make a commit to the README.md fixing a typo, now your build of the source code has a different checksum? I wonder why they don't instead hash all the source files and then embed that hash.
- Too 5y ago
  That doesn’t provide a link back to the source, unless you store that hash elsewhere. Giving you the problem of maintaining a database also.
  - pabs3 5y ago
    You store the source packages alongside the binary packages, and then index hashes of all the source/binary package contents. Then you know which source files were used from which source/binary packages to produce a particular executable.
- yawaramin 5y ago
  > So if you make a commit to the README.md fixing a typo, now your build of the source code has a different checksum? Yes...? What's the problem? > why they don't instead hash all the source files and then embed that hash. This is almost exactly what the git sha is. If you're arguing that README.md files shouldn't be included in the checksum, that's subjective. Many people would argue otherwise. And it doesn't hurt to be more accurate than less.
  - pabs3 5y ago
    The git commit hash is less accurate, since it includes extra files like README.md that aren't converted to any part of the executable.

nefitty 5y ago

My list of languages to practice were Scala and Rust. Maybe I'll do Scala and Go considering this single point.

ncmncm 5y ago
In other words, you are not actually interested in programming.

xxgreg 5y ago

There's also ongoing work to build a dependency vulnerability database. This is proposed to be surfaced via a built in `go audit` command. https://go.googlesource.com/proposal/+/master/design/draft-vulndb.md https://go.googlesource.com/proposal/+/master/design/draft-v...

derefr 5y ago

On Windows, the Microsoft compilers and linkers have inserted such toolchain/library version metadata into PE executables for decades now (the "RICH" header — https://bytepointer.com/articles/the_microsoft_rich_header.htm https://bytepointer.com/articles/the_microsoft_rich_header.h...). At the time that Microsoft started doing it, paranoiacs thought it was some kind of anti-piracy software fingerprinting mechanism, embedding the compiling computer's MAC address or something. But really, it serves exactly the same purpose that Golang's effort does here: to let you map compiled-artifact back to inputs.

pabs3 5y ago

So if you make a commit to the README.md fixing a typo, now your build of the source code has a different checksum? I wonder why they don't instead hash all the source files and then embed that hash.

Too 5y ago
That doesn’t provide a link back to the source, unless you store that hash elsewhere. Giving you the problem of maintaining a database also.
- pabs3 5y ago
  You store the source packages alongside the binary packages, and then index hashes of all the source/binary package contents. Then you know which source files were used from which source/binary packages to produce a particular executable.
yawaramin 5y ago
> So if you make a commit to the README.md fixing a typo, now your build of the source code has a different checksum? Yes...? What's the problem? > why they don't instead hash all the source files and then embed that hash. This is almost exactly what the git sha is. If you're arguing that README.md files shouldn't be included in the checksum, that's subjective. Many people would argue otherwise. And it doesn't hurt to be more accurate than less.
- pabs3 5y ago
  The git commit hash is less accurate, since it includes extra files like README.md that aren't converted to any part of the executable.