On Thu, May 21, 2026 at 09:14:57PM +0200, Dr. Tobias Quathamer wrote:
> Am 21.05.26 um 16:59 schrieb Adrian Bunk:
>...
> Hi Adrian,
Hi Tobias,
>...
> 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.
>...
> 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.
are you sure that using go.mod would get rid of the patch?
That's what I was talking about:
secsipidx-1.3.2$ cat go.mod
module github.com/asipto/secsipidx
go 1.16
require (
github.com/gomagedon/expectate v1.1.0
github.com/google/uuid v1.4.0
)
secsipidx-1.3.2$ go list -f '{{.DefaultGODEBUG}}' github.com/asipto/secsipidx
asynctimerchan=1,containermaxprocs=0,cryptocustomrand=1,decoratemappings=0,gotestjsonbuildtext=1,gotypesalias=0,httpcookiemaxnum=0,httplaxcontentlength=1,httpmuxgo121=1,httpservecontentkeepheaders=1,multipathtcp=0,netedns0=0,panicnil=1,randseednop=0,rsa1024min=0,tls10server=1,tls3des=1,tlsmlkem=0,tlsrsakex=1,tlssecpmlkem=0,tlssha1=1,tlsunsafeekm=1,updatemaxprocs=0,urlmaxqueryparams=0,urlstrictcolons=0,winreadlinkvolume=0,winsymlink=0,x509keypairleaf=0,x509negativeserial=1,x509rsacrt=0,x509sha256skid=0,x509usepolicies=0
secsipidx-1.3.2$ sed -i "s/go 1.16/go 1.24/g" go.mod
secsipidx-1.3.2$ go list -f '{{.DefaultGODEBUG}}' github.com/asipto/secsipidx
containermaxprocs=0,cryptocustomrand=1,decoratemappings=0,tlssecpmlkem=0,tlssha1=1,updatemaxprocs=0,urlstrictcolons=0,x509sha256skid=0
secsipidx-1.3.2$ sed -i "s/go 1.24/go 1.26/g" go.mod
secsipidx-1.3.2$ go list -f '{{.DefaultGODEBUG}}' github.com/asipto/secsipidx
secsipidx-1.3.2$
>...
> > 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?
I can reproduce the secsipidx FTBFS from your list by adding
export GODEBUG=rsa1024min=1
to debian/rules.[1]
> >> 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.
That's the generation of the misc:Static-Built-Using value,
I was thinking of missing usage in debian/control.
> Regards,
> Tobias
cu
Adrian
[1] below/instead of the obsolete GODEBUG=x509sha1=1
