On Thu, May 21, 2026 at 01:21:06PM +0200, Dr. Tobias Quathamer wrote: > Package: release.debian.org > Severity: normal > Control: affects -1 + src:dh-golang > User: [email protected] > Usertags: transition > X-Debbugs-Cc: [email protected], [email protected] > > Dear release team,
[ I am not a member of the release team ] > this is a summary of a conversation which I've just had with Helmut > Grohne on the phone. We've discussed the several options which are > available to resolve the security problems within the golang ecosystem. For people reading your email it would be helpful if you could provide a summary of what "the security problems" are. > First of all, I've just uploaded the golang compilers 1.25 and 1.26 to > unstable. Both contain the minimal patch which had been suggested by > Helmut, in order to support a new environment variable DEB_GOMINCOMPAT. > With this variable, we are able to set the golang compiler compatibility > version during package builds. >... Carrying a distribution patch for an actively developed compiler forever is not good. There is also a related issue that whatever problems and solution Debian wants are likely also desirable by other distributions. What is the actual problem and how could that be fixed upstream? Is my understanding correct that the version in the mandatory go directive in go.mod is documented as a minimum version, but it is also used as default setting for godebug with no way for go.mod to tell godebug "use the latest version"? If such semantics is really desired, the ability to overwrite default in the GODEBUG environment variable should be possible. > Most of the problematic settings (regarding security issues) are already > resolved in 1.24. From what I can tell, the only security related > difference between 1.24 and 1.26 is the setting "tlssha1=1". This flag > re-enables SHA-1 signature algorithms in TLS 1.2, which had been dropped > in Go 1.25. Is there a reason against setting a default GODEBUG in dh-golang (that debian/rules might override) containing only the relevant security settings? This would be a smaller change, and also avoid patching the compiler. > In order to actually use the new compatibility setting for our packages, > we would need to schedule binNMUs for 502 golang packages, which build > an executable binary. >... Do these 502 golang packages have the compiler in Built-Using or Static-Built-Using? If yes, then any changes will anyway get picked up by the next round of "Rebuild for outdated Built-Using" binNMUs the release team regularly does in unstable. If no, then this is a security problem within the golang ecosystem that should be be resolved - this information is needed for enabling binNMUs of statically linked Go binaries when a Go module package compiled into a binary got a security update. > Regards, > Tobias cu Adrian
