5 ms·

This is really useful. Almost every project I’ve worked on has had to have a build script in part to inject this info so it being a first class feature makes li

by Dobbs 5y ago

This is really useful. Almost every project I’ve worked on has had to have a build script in part to inject this info so it being a first class feature makes life just that much easier.

pvtmert 5y ago
At the same time, I was thinking how much of internal structure can be exposed. :)
- LysPJ 5y ago
  If there are projects where you don't want to reveal this info in the binary, you can turn the feature off with: -buildinfo=false
  - pvtmert 5y ago
    Yes, but it is turned on by default. And 99% of people will go and copy-paste existing tutorial code to their projects. I especially found out this is really useful for extracting information form non-stripped firmware binaries. They lay around on some S3 buckets, where cheap IoT manufacturers think it's safe to expose them online for updating purposes...
- deleted 5y ago
  [deleted]
- gwbas1c 5y ago
  Not much: > the currently checked-out revision and a flag indicating whether edited or untracked files are present Basically, it's including a git commit ID, which is a hash, and flags that indicate if there are local changes. It's pretty common to include build hashes in shipping code, logs, ect.
LysPJ 5y ago
Agreed. Anything that simplifies the build process and leads to less custom tooling is very welcome.
mytailorisrich 5y ago
The build version, embedded in the build, should match with a label or tag in source control so that this information should allow you to immediately get everything you need out of source control. In general you don't want more than that embedded in builds.
badjeans 5y ago
I found Nim's gorge command really useful. It runs a command at compile time and stores the output in a variable, so you can simply do things like: const compile_version = gorge "git describe --tags --always --dirty" const compile_time = gorge "date --rfc-3339=seconds"
- simse 5y ago
  That is very nice, thank you for sharing
- Philip-J-Fry 5y ago
  So simply compiling code could execute any random code? How is that safe?
  - capableweb 5y ago
    It's never safe to compile code, of course it can execute any random code, otherwise it would be useless...
    - TheDong 5y ago
      It's true that most languages's build systems (nim, rust, autotools, makefiles, etc) are unsafe to execute if you do not trust them. Go does stand in contrast to this. `go get` and `go build` cannot execute arbitrary code, and if you use those two commands to build untrusted code, in theory your machine should still remain uncompromised. They release CVEs for any issues here (such as https://github.com/golang/go/issues/29231 https://github.com/golang/go/issues/29231). Of course, if you run the code you compiled, that is unsafe, but just compiling it is supposed to be fine.
  - TheDong 5y ago
    It is the normal way of the world. Makefiles are arbitrary code execution. 'build.rs' in rust is the same. npm's package.json has an install script. Often this arbitrary code is to do things like run "pkg-config --libs" or such to find dependencies to link against, or generate some files that shouldn't be checked into source code, but rarely does it have sandboxing or other restrictions. Languages, like Go, which don't let a package execute arbitrary code on installation are the exception.

by Dobbs 5y ago

This is really useful. Almost every project I’ve worked on has had to have a build script in part to inject this info so it being a first class feature makes life just that much easier.

pvtmert 5y ago

At the same time, I was thinking how much of internal structure can be exposed. :)

LysPJ 5y ago
If there are projects where you don't want to reveal this info in the binary, you can turn the feature off with: -buildinfo=false
- pvtmert 5y ago
  Yes, but it is turned on by default. And 99% of people will go and copy-paste existing tutorial code to their projects. I especially found out this is really useful for extracting information form non-stripped firmware binaries. They lay around on some S3 buckets, where cheap IoT manufacturers think it's safe to expose them online for updating purposes...
deleted 5y ago
[deleted]
gwbas1c 5y ago
Not much: > the currently checked-out revision and a flag indicating whether edited or untracked files are present Basically, it's including a git commit ID, which is a hash, and flags that indicate if there are local changes. It's pretty common to include build hashes in shipping code, logs, ect.

LysPJ 5y ago

Agreed. Anything that simplifies the build process and leads to less custom tooling is very welcome.

mytailorisrich 5y ago

The build version, embedded in the build, should match with a label or tag in source control so that this information should allow you to immediately get everything you need out of source control. In general you don't want more than that embedded in builds.

badjeans 5y ago

I found Nim's gorge command really useful. It runs a command at compile time and stores the output in a variable, so you can simply do things like: const compile_version = gorge "git describe --tags --always --dirty" const compile_time = gorge "date --rfc-3339=seconds"

simse 5y ago
That is very nice, thank you for sharing
Philip-J-Fry 5y ago
So simply compiling code could execute any random code? How is that safe?
- capableweb 5y ago
  It's never safe to compile code, of course it can execute any random code, otherwise it would be useless...
  - TheDong 5y ago
    It's true that most languages's build systems (nim, rust, autotools, makefiles, etc) are unsafe to execute if you do not trust them. Go does stand in contrast to this. `go get` and `go build` cannot execute arbitrary code, and if you use those two commands to build untrusted code, in theory your machine should still remain uncompromised. They release CVEs for any issues here (such as https://github.com/golang/go/issues/29231 https://github.com/golang/go/issues/29231). Of course, if you run the code you compiled, that is unsafe, but just compiling it is supposed to be fine.
- TheDong 5y ago
  It is the normal way of the world. Makefiles are arbitrary code execution. 'build.rs' in rust is the same. npm's package.json has an install script. Often this arbitrary code is to do things like run "pkg-config --libs" or such to find dependencies to link against, or generate some files that shouldn't be checked into source code, but rarely does it have sandboxing or other restrictions. Languages, like Go, which don't let a package execute arbitrary code on installation are the exception.