"Dr. Tobias Quathamer" <[email protected]> writes: > Am 24.06.26 um 13:15 schrieb Andrew Lee: >> Hi Simon, >> >> On Wed, Jun 24, 2026 at 12:19 PM Simon Josefsson <[email protected]> wrote: >>> What is your recommendation? Add 'export DEB_GOMINCOMPAT:=1.24' to >>> debian/rules? Or something related to GO111MODULES? > > Hi Simon,
Thanks for explaining! I agree the long-term solution to this seems complex, so thanks for thinking and working towards addressing that. > please avoid to set DEB_GOMINCOMPAT manually in d/rules, unless > absolutely needed for critical security fixes. What if setting that is required to get the package to work at all? It seems the litewitness binary built by 'torchwood' doesn't work (HTTP 404 errors) without that flag. What if setting the flag is required to make self-checks pass (as invoked by dh_auto_test during normal builds, so failure leads to FTBFS unless ignored)? The test infrastructure for 'sigsum-go' triggers this problem: https://git.glasklar.is/sigsum/core/sigsum-go/-/work_items/93 What is a "critical" security problem? Is TLS 1.0 a "critical" vulnerability or not? RSA 1024 bit keys? RSA-SHA1? I think it depends on the application, end-user and threat model, and it is hard to make a general decision here, so I would prefer to go with upstream Go defaults that disable TLS 1.0, RSA 1024 bit keys, RSA-SHA1, etc. And that would argue for setting DEB_GOMINCOMPAT to get that behaviour. Thus, I'm not so sure it is practical to have a stringent policy to not use the flag when using it improves actual problems. > Please note that this patch to the golang compiler (supporting > DEB_GOMINCOMPAT) is intended to be short-lived. I plan to remove the > patch before the release of forky, so please do not rely on that behavior. I suppose you wouldn't remove it in a way that turn the Debian Go ecosystem back into the problematic behaviour? So it seems okay to assume that setting DEB_GOMINCOMPAT turns Debian Go into a "modern" Go, and then rely on that behaviour to the point of FTBFS if that turns out to no longer holds (so that a maintainer can decide how to resolve it later on). I think this is acceptable for torchwood and sigsum-go, which are security relevant pieces of software. /Simon > I've implemented support for the variable in the dh-golang helper script > and filed a transition bug. For more context, please see > https://bugs.debian.org/1137232. Unfortunately, that bug is stalled > right now. > > However, I've been working in parallel on implementing the module-aware > build in dh-golang, based on the ideas in Andrews proof-of-concept > script. I think that is nearly done, but not quite. > > Regards, > Tobias >
signature.asc
Description: PGP signature
