Am 21.05.26 um 16:59 schrieb Adrian Bunk: >> 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.
Hi Adrian, true -- sorry for that. We've had many mails with the release and security team during the time when this had not been disclosed, so they do have enough context. But people reading this the first time do not. A very short summary is that the golang compiler enables compatibility settings for legacy packages via DefaultGODEBUG flags. Some of those flags allow creating RSA keys < 1024 bits, TLS 1.0, SHA1 etc., basically discarding modern security standards. Right now, due to the way Debian builds its golang packages, every executable binary is allowed to use insecure settings during execution. See the talk of Andrew Lee at MiniDebconf Hamburg for more details. https://meetings-archive.debian.net/pub/debian-meetings/2026/MiniDebConf-Hamburg/hamburg2026-85-rescue-forky-we-have-go-back-to-2011-building-go-like-its-2011-is-broken.lq.webm >> 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. Our plan is to mitigate the immediate problems with a simple patch, which did work out really well during our test rebuilds. It's not planned to keep this patch forever. Quite the contrary, our hopes are that we might get rid of it before Forky is released. Regarding your second point: as it turns out, this is a problem only specific to Debian, due to the old (and by today's standards in the golang language obsolete) way of building golang packages. We completely ignore go.mod files and turn GO111MODULE=off during build. Due to this, the compiler basically falls back to a compatibility level of golang-1.0, released in 2012. From what I understand, all other major distributions do not use this approach, but do use the go.mod files for building their packages. > What is the actual problem and how could that be fixed upstream? See above, it's not an upstream problem, this is specific only for Debian builds. > 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"? Yes, that's how I understand it as well. Note that the version in the go.mod file of the "main" package is used, it's not the minimal go version from all dependencies combined. > If such semantics is really desired, the ability to overwrite default in > the GODEBUG environment variable should be possible. > > 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. I don't quite understand what you mean here. Could you elaborate? >> 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. I don't know -- we've calculated the list of packages based on their use of golang-compilers in Build-Depends. I guess that most (all?) packages do have the compiler in Static-Built-Using, unless they are *really* old. The use of Static-Built-Using has been implemented in dh-golang in April 2022, released as version 1.55. Even oldstable has 1.59. Regards, Tobias
OpenPGP_signature.asc
Description: OpenPGP digital signature
