Damn, I keep forgetting that I had other stuff to say: My main concern with this approach is that the BuildInfo embedded into binaries is incomplete in a bunch of circumstances - for example, if you clone the repository and run `go build` in it (I believe) or if someone uses a `goimports` version with local modifications that otherwise behaves like some upstream version. It's *probably* fine and even intended for the version information to be missing and considered incompatible in those cases, but it's a caveat I found when trying to use BuildInfo in practice.
On Fri, 18 Oct 2024 at 09:20, Axel Wagner <axel.wagner...@googlemail.com> wrote: > On Fri, 18 Oct 2024 at 08:20, Kurtis Rader <kra...@skepticism.us> wrote: > >> And, obviously, how do you handle a command named "goimports" installed >> by the user that is not from the golang.org/x/tools repository. >> > > I'll note that it should be trivial to check if the BuildInfo.Main.Path is > golang.org/x/tools and BuildInfo.Path is golang.org/x/tools/cmd/goimports. > Obviously, it's possible that a user has a carefully crafted binary that > contains lying build information in the corresponding ELF sections. But > let's not have the perfect be the enemy of the good enough. > -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/CAEkBMfFFCxFMWbo_7AiQe3MVetzAPNDsGYOAKAgfSbRNcD7VoQ%40mail.gmail.com.
