Suggested advisory:
========================

The updated packages fix security vulnerabilities:

net/http: sensitive headers incorrectly sent after cross-domain redirect. (CVE-2024-45336)

crypto/x509: usage of IPv6 zone IDs can bypass URI name constraints. (CVE-2024-45341)

References:
https://www.openwall.com/lists/oss-security/2025/01/17/1
========================

Updated packages in core/updates_testing:
========================
golang-1.22.11-1.mga9
golang-bin-1.22.11-1.mga9
golang-docs-1.22.11-1.mga9
golang-misc-1.22.11-1.mga9
golang-shared-1.22.11-1.mga9
golang-src-1.22.11-1.mga9
golang-tests-1.22.11-1.mga9

from SRPM:
golang-1.22.11-1.mga9.src.rpm

Whiteboard: MGA9TOO => (none)
Assignee: bugsquad => qa-bugs
Source RPM: golang-1.23.3-1.mga10.src.rpm, golang-1.22.9-1.mga9.src.rpm => golang-1.22.9-1.mga9.src.rpm
Version: Cauldron => 9
Status: NEW => ASSIGNED
Status comment: Fixed upstream in 1.23.5 and 1.22.11 => (none)

Used to build docker with success

CC: (none) => andrewsfarm
Whiteboard: (none) => MGA9-64-OK

Validating.

Keywords: (none) => validated_update
CC: (none) => sysadmin-bugs

Given go's pechant for static linking, every go program that uses these two packages needs to be rebuilt as well.

CC: (none) => dan

An update for this issue has been pushed to the Mageia Updates repository.

https://advisories.mageia.org/MGASA-2025-0021.html

Status: ASSIGNED => RESOLVED
Resolution: (none) => FIXED

*penchant for static linking

I've reopened this bug until we identify what go binaries need to be rebuilt. We aren't currently tracking go binary dependencies that I know of, so I don't think this is going to be super easy. Running "go version -m path/to/binary" will shows the external dependencies built-in to a go binary, but not the language's standard packages. I don't see how we can do this without either scanning the source code of each go program in the distribution or just rebuilding every single go package.

In any case, updating the golang package as done in this bug still leaves all packages in Mageia using net/http or crypto/x509 vulnerable to these CVEs. And unless something was done earlier, also vulnerable to the CVEs in #33197 #33269 #33380 and #33526 as well.

Status: RESOLVED => REOPENED
Resolution: FIXED => (none)

Adding Pascal for his opinion on go rebuilds.

CC: (none) => pterjan

We've had this issue with golang-* module/library/whatever packages as well in the past, and never came up with a solution.

This is leaving our users vulnerable. We need to come up with something.

I count only 104 leaf go packages ATM. Rebuilding them all after a golang update wouldn't be a ridiculous solution.

Yes for golang itself we probably need to rebuild all non monarch packages having it installed at build time.

For other golang-* we could get more targeted information. A few years ago I looked into building something but them they launched https://go.dev/blog/vuln so I decided to wait and see if we can use that

(My phone corrected noarch into monarch in previous comment)

For other golang-* packages, do we need to do anything after a golang update? They aren't actually built at RPM creation time, so the the resulting packages should be bit-for-bit identical, regardless of the golang version, right?

Or are you talking about vulnerabilities fixed in other golang-* packages? In that case, with the current infrastructure and packaging guidelines there should always be BuildRequires: that we can use to find dependent packages to rebuild.

Yes I mean for vulnerabilities in other golang- packages.
We don't need to rebuild again other noarch packages for the same reason but transitive non noarch ones. 

However often they will not use anything from it, they use a few functions from a file in a package containing other files which pull in some dependencies they don't use. For example the cloud API client ones, if you use one API method you will pull in dependencies needed by thousands of methods but not link them in in the end. And even within a file, the function which is called may not need other dependencies needed by other functions in that file.

That's why they provide this tool which looks at which exact functions some code actually links in in the end to see if it is potentially impacted by a vulnerability (if it links the code with the vulnerability). Do it could allow much more targeted rebuilds.

I've opened bug #33973 on the rebuilds now necessary to pick up this Go security fix and other fixes to fix many of our packages. I've also started https://wiki.mageia.org/en/Vendored_dependencies with a (skeletal) proposal on how to handle these kinds of rebuilds long-term. There are also a few links there to what Fedora is starting to do about this general problem.

Resolution: (none) => FIXED
Status: REOPENED => RESOLVED