Bug 30218

Summary: golang-x-net new security issue CVE-2021-33194
Product: Mageia Reporter: David Walser <luigiwalser>
Component: SecurityAssignee: Guillaume Rousse <guillomovitch>
Status: RESOLVED OLD QA Contact: Sec team <security>
Severity: normal    
Priority: Normal CC: guillomovitch, nicolas.salguero, tarazed25
Version: 8   
Target Milestone: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Source RPM: golang-x-net-0-0.6.mga8.src.rpm CVE:
Status comment:

Description David Walser 2022-03-29 01:41:28 CEST
Fedora has issued an advisory on March 26:
https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/thread/4CHKSFMHZVOBCZSSVRE3UEYNKARTBMTM/

CVE-2021-33194 is actually in golang-x-net and was fixed upstream in 2021.  Mageia 8 needs to be updated to the same snapshot that's in Cauldron.
Comment 1 David Walser 2022-05-14 18:09:58 CEST
Updated package uploaded for Cauldron by Guillaume.

golang-x-net-devel-0-0.6.1.mga8
golang-x-net-http-devel-0-0.6.1.mga8

from golang-x-net-0-0.6.1.mga8.src.rpm

Assignee: guillomovitch => qa-bugs
CC: (none) => guillomovitch

Comment 2 Len Lawrence 2022-05-16 13:16:19 CEST
mga8, x64
There appears to be nothing which depends on these packages which are not themselves development packages so this should be passed if they install cleanly.  So far they do not.

Sorry, the following package cannot be selected:

- golang-x-net-http-devel-0-0.6.1.mga8.noarch (due to unsatisfied golang(golang.org/x/term))

$ rpm -q golang-x-net-devel
golang-x-net-devel-0-0.6.1.mga8

$ urpmq --whatrequires golang-x-net-http-devel
golang-etcd-devel
golang-github-aws-sdk-devel
golang-github-git-lfs-devel
golang-github-google-devel
golang-github-jcmturner-rpc-devel
golang-github-onsi-gomega-devel
golang-github-prometheus-common-promlog-devel
golang-github-shurcool-httpgzip-devel
golang-github-soheilhy-cmux-devel
golang-github-ssgelm-cookiejarparser-devel
golang-google-grpc-status-devel
golang-grpc-go4-devel
golang-x-build-devel
golang-x-crypto-devel

Setting feedback marker.

Keywords: (none) => feedback
CC: (none) => tarazed25

Comment 3 David Walser 2022-11-08 23:43:14 CET
Guillaume, see the issue in Comment 2.

Also, does this fix CVE-2022-1705 and CVE-2022-32148?
https://access.redhat.com/errata/RHSA-2022:7529

Keywords: feedback => (none)
Assignee: qa-bugs => guillomovitch

Comment 4 David Walser 2022-11-08 23:54:01 CET
(In reply to David Walser from comment #3)
> Also, does this fix CVE-2022-1705 and CVE-2022-32148?
> https://access.redhat.com/errata/RHSA-2022:7529

Also CVE-2021-36221:
https://access.redhat.com/errata/RHSA-2022:7457
Comment 5 David Walser 2022-11-15 23:28:19 CET
Also CVE-2021-33197:
https://access.redhat.com/errata/RHSA-2022:7954
Comment 7 Guillaume Rousse 2023-04-21 22:08:56 CEST
All vulnerabilites referenced here seems to be related with go itself, not with golang-x-net. The only one where golang-x-net is cited explicitely (CVE-2022-41723) mention 0.7 as the version fixing the issue, which is current cauldron version.

If I understand correctly how go static linking works, we should check that everything relying on golang-x-net has been rebuild since this new version release (Sun Feb 26). That's quite easy for direct dependencies (60 different packages, all of them being other go library), but that doesn't cover transitive dependencies...

It seems our current update policy doesn't scale with this kind of issue. How do other distribution handle it ?
Comment 8 David Walser 2023-04-22 01:09:21 CEST
I have seen Fedora rebuild dozens of packages for these kinds of issues, but their build system and procedures makes that a lot easier to manage.  I've seen more limited sets of rebuilds in some other distros, and nothing at all from some.  We have done updates that required lots of rebuilds before, but usually because of binary-incompatible library updates, not typically for compiler issues.
Comment 9 Nicolas Salguero 2024-01-12 09:42:51 CET
Mageia 8 EOL

Resolution: (none) => OLD
Status: NEW => RESOLVED
CC: (none) => nicolas.salguero