Hi Adrian, sorry for the delay, I've mostly been AFK.
Am 22.05.26 um 00:00 schrieb Adrian Bunk:
> are you sure that using go.mod would get rid of the patch?
Yes, I think that when dh_golang is rewritten to make use of the go.mod
files from upstream, the patch should be dropped.
However:
I did some more experiments in the last days, to make sense of how the
golang compiler determines the compatibility settings. When a main
module is compiled (resulting in an executable), the language features
of the golang version specified in that module's go.mod file are used.
So in your example with secsipidx, indeed the compiler will use
compatibility settings for golang 1.16, therefore enabling lots of
insecure flags.
I'm not sure how to avoid this. Maybe the line with "go 1.16" in the
go.mod file would need to be patched by dh_golang to "1.24" or higher.
>>> 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]
Ok, I see. You're right, this approach doesn't need a patch for the go
compiler. However, it's not trivial to come up with a list of needed
flags for the GODEBUG environment variable. Go has introduced several
flags in the last years, some of which have been removed again in the
meantime. Also, every time a new go compiler version get uploaded (1.27
etc.), this list needs to be revisited.
I would be in favor of patching the golang compiler for now, until the
Debian golang ecosystem has made the switch to using go.mod files. This
way, we get all flags which are currently applicable with a single
setting for the golang compatibility settings.
After rewriting dh_golang to make use of the go.mod files, the building
of golang packages within Debian should then be very similar to the way
other distributions build their golang packages.
>>>> 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.
Okay. I didn't look at all ~3000 golang packages, obviously. But I doubt
that Build-Using is in wide use. Why would the generated list in
${misc:Static-Built-Using} not be enough to determine which packages
need a rebuild?
Regards,
Tobias
OpenPGP_signature.asc
Description: OpenPGP digital signature
