Am 24.06.26 um 14:48 schrieb Simon Josefsson: >> 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.
Sure, that sounds like the setting is needed. Or maybe GODEBUG, see below. > 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 I'd say the setting is needed as well. > 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 Sure, it depends on the application. For example, if your application does not use RSA keys at all, it does not matter if RSA keys with 25 bits would be allowed. Same with all other security relevant settings. > 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. Right, it would be sensible to use the version from upstream's go.mod file as the compatibility level. > 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. Well, as I've said above: if it fixes the build of your package, you might use it. But it might be better to use GODEBUG. >> 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 No, I wouldn't agree with this conclusion. The patch is rather a dirty hack to force the compiler to do things it wouldn't normally do, so it's far from being "modern" Go. It's a clumsy workaround, which has been mainly targeted at stable, due to the minimal changes needed. The patch does nothing about respecting go.mod files, the compiler is still using the old and obsolete GOPATH mode. For unstable, this is not the right approach to fix the problems in our golang ecosystem. Maybe you're even better off by using Mathias' advice and set the GODEBUG variable in d/rules. That is at least an official way to influence the build, while DEB_GOMINCOMPAT is only available in Debian and is intended to be short-lived. Regards, Tobias
OpenPGP_signature.asc
Description: OpenPGP digital signature
