On 12/07/26 7:50 pm, Andrew Lee wrote: > On Sun, Jul 12, 2026 at 3:26 PM Nilesh Patra <[email protected]> wrote: >>> "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] >> be a bit better, please suggest if something else would sound better. > > I would suggest to use `go-binary-contains-godebug-overrides` instead > of `defaultgodebug-options` to avoid confusion. > > The phrase "defaultgodebug" makes it sound like a standard go default, > which is not what upstream intends.
I renamed it to "binary-contains-insecure-defaultgodebug-settings". Does that sound OK? Override generally means maintainer overrides (than upstream or compiler gen), so I'd rather not use that wording. On 12/07/26 8:22 pm, Dr. Tobias Quathamer wrote: > If the MR makes it into lintian now, I think that "info" or even > "pedantic" might be a better choice, as long as Debian still uses > GO111MODULE=off as default setting. I'm planning to merge this, yes. I've changed the level to pedantic for now. > When that has changed in dh-golang, the check you've written could be > bumped in severity to a warning. > > For the explanation, you might consider this text: > > > The binary contains legacy or insecure DefaultGODEBUG variable settings. > > Modern Go versions allow developers to force legacy (and potentially > insecure) behaviors using //go:debug directives or GODEBUG settings. > While these are sometimes necessary for temporary compatibility, they > can introduce security vulnerabilities, disable critical fixes, or > compromise build reproducibility. Added. Could you please review the MR and comment on it, please? > Am 12.07.26 um 15:26 schrieb Nilesh Patra: >> Not sure how useful the individual options are, I wonder if it makes >> sense to not emit them at all. > Currently, the list is really long, yes. So it might make sense to just > emit the tag without the specific DefaultGODEBUG settings. > > However, when the go packages are build with GO111MODULE=on, that list > should normally be empty. In that case, if there are only very few > options listed, I think it would help the maintainer to see which > options were used, in order to determine why those settings were used > and if they are really needed. > > My understanding is that the Debian archive would need binNMUs for all > golang packages which produce an executable, to be rebuilt in a > module-aware fashion. Afterwards, the list should be empty for almost > all packages. I just cut a release today, and lintian release happens roughly every month. Given that some work on dh-golang has already happened, would 1 month be a fair enough time for this? Thanks, Nilesh
