On 12/07/26 3:33 pm, Dr. Tobias Quathamer wrote:
> Andrew did write a shell script in his proof-of-concept, which can
> analyze a go binary and detect the settings which were used during
> compilation. At the MiniDebconf Hamburg, we've implemented that logic in
> a perl script for dh_golang. You can see the script in this repository:
>
> https://salsa.debian.org/toddy/dh-golang/-/blob/go-work/script/dh_golang_check_debug
>
> The essential check (the "audit") can be found in line 79. Basically,
> all the script does is to run "go version -m $BINARY" for each binary in
> the $BUILDDIR/usr/bin directory and emit a warning if the variable
> "DefaultGODBUG" is found.
Got it. I've written a check and it emits the following for hugo:
W: hugo: binary-contains-defaultgodebug-options
asynctimerchan=1,containermaxprocs=0,cryptocustomrand=1 ... [/usr/bin/hugo]
(I've trimmed the output in the mail)
Please review my MR [1], and let me know if they are inline with your
expectations. The tag description can probably
be a bit better, please suggest if something else would sound better.
Not sure how useful the individual options are, I wonder if it makes sense to
not emit them at all.
> My personal feeling is that lintian should emit a warning if DefaultGODEBUG
> is detected in a binary.
I'm worried if this will annoy maintainers. As a downstream maintainer, unless
someone tries a patch
to explicitly use DefaultGODEBUG, I am not sure what they can do about it, as
this could be coming
directly off upstream.
Do you have suggestions to fix this if found in a downstream package?
I tried digging around for a way to fix this for hugo for instance but don't
find anything obvious. OTOH, more
verbose compilation suggests these come from compiler itself. If one runs
`go version -m /usr/bin/hey` or `go version -m /usr/bin/certinfo` these options
are everywhere.
[1] https://salsa.debian.org/lintian/lintian/-/merge_requests/755
Thanks,
Nilesh
