Bug 30743 - unbound new security issues CVE-2022-3069[89]
Summary: unbound new security issues CVE-2022-3069[89]
Status: RESOLVED FIXED
Alias: None
Product: Mageia
Classification: Unclassified
Component: Security (show other bugs)
Version: 8
Hardware: All Linux
Priority: Normal major
Target Milestone: ---
Assignee: QA Team
QA Contact: Sec team
URL:
Whiteboard: MGA8-64-OK
Keywords: advisory, validated_update
Depends on:
Blocks:
 
Reported: 2022-08-12 19:05 CEST by David Walser
Modified: 2022-08-25 23:23 CEST (History)
5 users (show)

See Also:
Source RPM: unbound-1.13.0-2.mga8.src.rpm
CVE:
Status comment:


Attachments

Description David Walser 2022-08-12 19:05:23 CEST
Fedora has issued an advisory today (August 12):
https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/thread/5L3ZFWZZFPBIL654BG75RWXUMPFQJ5EC/

The issues are fixed upstream in 1.16.2.

Mageia 8 is also affected.
David Walser 2022-08-12 19:05:34 CEST

Status comment: (none) => Fixed upstream in 1.16.2
Whiteboard: (none) => MGA8TOO

Comment 1 David Walser 2022-08-17 18:40:21 CEST
Ubuntu has issued an advisory for this on August 16:
https://ubuntu.com/security/notices/USN-5569-1
Comment 2 christian barranco 2022-08-20 10:55:34 CEST
Hi. Do you need any support?
The MGA8 version is now quite old.

CC: (none) => chb0

Comment 3 christian barranco 2022-08-21 14:07:01 CEST
Hi. I just succeeded to build it locally.
Cauldron is up-to-date. 
If you allow me, I can take it an update MGA8.
Comment 4 christian barranco 2022-08-21 16:41:19 CEST
Hi again. After discussing with Luigi on IRC, I take it on, while eatdirt is out.

Version: Cauldron => 8
Whiteboard: MGA8TOO => (none)
Source RPM: unbound-1.15.0-1.mga9.src.rpm => unbound-1.13.0-2.mga8.src.rpm
Assignee: eatdirt => chb0

Comment 5 christian barranco 2022-08-21 23:12:26 CEST
Hi. Ready for QA.



ADVISORY NOTICE PROPOSAL
========================
Updated unbound packages fix security vulnerabilities and bugs


Description
Update to version 1.16.2 fixes many bugs (along with versions 1.13.1, 1.13.2, 1.14.0, 1.15.0, 1.16.0 and 1.16.1), and protects against CVE-2022-3069[89]
           
References
https://bugs.mageia.org/show_bug.cgi?id=30743
https://github.com/NLnetLabs/unbound/releases/tag/release-1.13.1
https://github.com/NLnetLabs/unbound/releases/tag/release-1.13.2
https://github.com/NLnetLabs/unbound/releases/tag/release-1.14.0
https://github.com/NLnetLabs/unbound/releases/tag/release-1.15.0
https://github.com/NLnetLabs/unbound/releases/tag/release-1.16.0
https://github.com/NLnetLabs/unbound/releases/tag/release-1.16.1
https://github.com/NLnetLabs/unbound/releases/tag/release-1.16.2
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-30698
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-30699


SRPMS
8/core
unbound-1.16.2-1.mga8.src.rpm


PROVIDED PACKAGES:

lib64unbound8-1.16.2-1.mga8
lib64unbound-devel-1.16.2-1.mga8
unbound-1.16.2-1.mga8
python3-unbound-1.16.2-1.mga8


    
PACKAGES FOR QA TESTING
=======================
x86_64:

lib64unbound8-1.16.2-1.mga8.x86_64.rpm
lib64unbound-devel-1.16.2-1.mga8.x86_64.rpm
unbound-1.16.2-1.mga8.x86_64.rpm
python3-unbound-1.16.2-1.mga8.x86_64.rpm


i586:

lib64unbound8-1.16.2-1.mga8.i586.rpm
lib64unbound-devel-1.16.2-1.mga8.i586.rpm
unbound-1.16.2-1.mga8.i586.rpm
python3-unbound-1.16.2-1.mga8.i586.rpm

Assignee: chb0 => qa-bugs
CC: (none) => eatdirt, sysadmin-bugs

Comment 6 christian barranco 2022-08-21 23:25:41 CEST
Test done on Plasma x86_64

Update from 1.13.0 using QArepo.

Service restart on 1.16.2

2 subsequent "dig mageia.org" confirm local server is used and inquiry is cached:

$ dig mageia.org   #first command

; <<>> DiG 9.11.37Mageia-1.mga8 <<>> mageia.org
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 27700
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
;; QUESTION SECTION:
;mageia.org.                    IN      A

;; ANSWER SECTION:
mageia.org.             1800    IN      A       163.172.148.228

;; Query time: 358 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: dim. août 21 23:21:28 CEST 2022
;; MSG SIZE  rcvd: 55


$ dig mageia.org   #second command

; <<>> DiG 9.11.37Mageia-1.mga8 <<>> mageia.org
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 9708
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
;; QUESTION SECTION:
;mageia.org.                    IN      A

;; ANSWER SECTION:
mageia.org.             1785    IN      A       163.172.148.228

;; Query time: 0 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: dim. août 21 23:21:43 CEST 2022
;; MSG SIZE  rcvd: 55
David Walser 2022-08-21 23:30:10 CEST

Status comment: Fixed upstream in 1.16.2 => (none)
CC: sysadmin-bugs => (none)

Comment 7 Herman Viaene 2022-08-22 15:39:20 CEST
MGA8-64 Plasma on Acer Aspire 5253
No installation issues
Ref bug 28447 Comment 4 for testing
# systemctl  start unbound
# systemctl  -l status unbound
● unbound.service - Unbound DNS Resolver
     Loaded: loaded (/usr/lib/systemd/system/unbound.service; disabled; vendor preset: disabled)
     Active: active (running) since Mon 2022-08-22 15:33:41 CEST; 2s ago
   Main PID: 23434 (unbound)
      Tasks: 1 (limit: 4364)
     Memory: 5.9M
        CPU: 95ms
     CGroup: /system.slice/unbound.service
             └─23434 /usr/sbin/unbound -c /etc/unbound/unbound.conf

Aug 22 15:33:41 mach7.hviaene.thuis systemd[1]: Started Unbound DNS Resolver.
Aug 22 15:33:41 mach7.hviaene.thuis unbound[23434]: [23434:0] notice: init module 0: validator
Aug 22 15:33:41 mach7.hviaene.thuis unbound[23434]: [23434:0] notice: init module 1: iterator
Aug 22 15:33:41 mach7.hviaene.thuis unbound[23434]: [23434:0] info: start of service (unbound 1.16.2).

But repeating Christian's test above
$ dig mageia.org

; <<>> DiG 9.11.37Mageia-1.mga8 <<>> mageia.org
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 47331
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 6, ADDITIONAL: 13

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
; COOKIE: 784ec1d68f074cda601f2bfd630385c65e11f4d2f2485811 (good)
;; QUESTION SECTION:
;mageia.org.                    IN      A

;; ANSWER SECTION:
mageia.org.             1290    IN      A       163.172.148.228

;; AUTHORITY SECTION:
org.                    147882  IN      NS      a0.org.afilias-nst.info.
org.                    147882  IN      NS      b0.org.afilias-nst.org.
org.                    147882  IN      NS      d0.org.afilias-nst.org.
org.                    147882  IN      NS      b2.org.afilias-nst.org.
org.                    147882  IN      NS      a2.org.afilias-nst.info.
org.                    147882  IN      NS      c0.org.afilias-nst.info.

;; ADDITIONAL SECTION:
d0.org.afilias-nst.org. 147882  IN      A       199.19.57.1
c0.org.afilias-nst.info. 147882 IN      A       199.19.53.1
a0.org.afilias-nst.info. 147882 IN      A       199.19.56.1
b0.org.afilias-nst.org. 147882  IN      A       199.19.54.1
b2.org.afilias-nst.org. 147882  IN      A       199.249.120.1
a2.org.afilias-nst.info. 147882 IN      A       199.249.112.1
d0.org.afilias-nst.org. 147882  IN      AAAA    2001:500:f::1
c0.org.afilias-nst.info. 147882 IN      AAAA    2001:500:b::1
a0.org.afilias-nst.info. 147882 IN      AAAA    2001:500:e::1
b0.org.afilias-nst.org. 147882  IN      AAAA    2001:500:c::1
b2.org.afilias-nst.org. 147882  IN      AAAA    2001:500:48::1
a2.org.afilias-nst.info. 147882 IN      AAAA    2001:500:40::1

;; Query time: 3 msec
;; SERVER: 192.168.2.1#53(192.168.2.1)
;; WHEN: Mon Aug 22 15:33:58 CEST 2022
;; MSG SIZE  rcvd: 485

This laptop via wifi is in a LAN with a local DNS server, and I see that the server line points to this server, not to the unbound on local host. I have no idea how to change this network behavior.

CC: (none) => herman.viaene

Comment 8 christian barranco 2022-08-22 18:07:02 CEST
Hi Herman
Was it behaving like that before?

In /etc/resolv.conf do you have

# Dynamic resolv.conf(5) file for glibc resolver(3) generated by resolvconf(8)
#     DO NOT EDIT THIS FILE BY HAND -- YOUR CHANGES WILL BE OVERWRITTEN
nameserver 127.0.0.1
Comment 9 Dave Hodgins 2022-08-22 19:25:26 CEST
Note /etc/resolv.conf is a generated using the files in
/etc/resolvconf/resolv.conf.d/

I have ...
# cat /etc/resolvconf/resolv.conf.d/head 
# Dynamic resolv.conf(5) file for glibc resolver(3) generated by resolvconf(8)
#     DO NOT EDIT THIS FILE BY HAND -- YOUR CHANGES WILL BE OVERWRITTEN
nameserver ::1
nameserver 127.0.0.1

With bind being used on localhost for dns.

Putting the entries in the head file prepends them before anything added
by drakx-net or networkmanager.

CC: (none) => davidwhodgins

Comment 10 Herman Viaene 2022-08-23 08:37:57 CEST
I never touch resolv.conf, I give each machine in my LAN a fixed IP-address which is registered in the DNS-server I run on my main dekstop PC. And that's the one you see in the "Server" line at the end of the feedback of the dig command.
Comment 11 David Walser 2022-08-23 13:14:57 CEST
Unbound is a DNS server.  You can either change resolv.conf to make your computer test it, or you can test it directly with nslookup (there's probably a way with dig, check the man page) by giving 127.0.0.1 as a second argument.
Comment 12 christian barranco 2022-08-23 23:18:52 CEST
Hi Herman
You don’t need to change resolv.conf manually. I asked about it to understand your configuration. 
What you can do is to change dns to 127.0.0.1 with net_applet or networkmanager to test; then, you revert back.
Comment 13 christian barranco 2022-08-23 23:19:04 CEST
Hi Herman
You don’t need to change resolv.conf manually. I asked about it to understand your configuration. 
What you can do is to change dns to 127.0.0.1 with net_applet or networkmanager to test; then, you revert back.
Comment 14 christian barranco 2022-08-23 23:21:04 CEST
Sorry, tablet glitch. You got my comment twice….
Comment 15 Herman Viaene 2022-08-24 09:23:46 CEST
Followed suggestion,set dns to 127.0.0.1
Then
# systemctl  start unbound
# systemctl  -l status unbound
● unbound.service - Unbound DNS Resolver
     Loaded: loaded (/usr/lib/systemd/system/unbound.service; disabled; vendor preset: disabled)
     Active: active (running) since Wed 2022-08-24 09:17:56 CEST; 5s ago
   Main PID: 3940 (unbound)
      Tasks: 1 (limit: 4364)
     Memory: 7.3M
        CPU: 106ms
     CGroup: /system.slice/unbound.service
             └─3940 /usr/sbin/unbound -c /etc/unbound/unbound.conf

Aug 24 09:17:56 mach7.hviaene.thuis systemd[1]: Started Unbound DNS Resolver.
Aug 24 09:17:56 mach7.hviaene.thuis unbound[3940]: [3940:0] notice: init module 0: validator
Aug 24 09:17:56 mach7.hviaene.thuis unbound[3940]: [3940:0] notice: init module 1: iterator
Aug 24 09:17:56 mach7.hviaene.thuis unbound[3940]: [3940:0] info: start of service (unbound 1.16.2).

And

$ dig mageia.org

; <<>> DiG 9.11.37Mageia-1.mga8 <<>> mageia.org
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 64761
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
;; QUESTION SECTION:
;mageia.org.                    IN      A

;; Query time: 4042 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Wed Aug 24 09:18:24 CEST 2022
;; MSG SIZE  rcvd: 39

That's not OK, I guess.
Comment 16 christian barranco 2022-08-24 17:52:12 CEST
(In reply to Herman Viaene from comment #15)
> 
> ;; Query time: 4042 msec
> ;; SERVER: 127.0.0.1#53(127.0.0.1)
> ;; WHEN: Wed Aug 24 09:18:24 CEST 2022
> ;; MSG SIZE  rcvd: 39
> 
> That's not OK, I guess.

It is ok. 127.0.0.1 is used as dns server. 
If you run the dig query twice, you should then get 
Query time: 0 msec
showing the query has been cached
Comment 17 Dave Hodgins 2022-08-24 20:01:14 CEST
Herman is correct. There is something wrong.
# netstat -tapn|grep unbound
tcp        0      0 127.0.0.1:53            0.0.0.0:*               LISTEN      40357/unbound       
tcp6       0      0 ::1:53                  :::*                    LISTEN      40357/unbound
[root@x3 ~]# dig ANY mageia.org

; <<>> DiG 9.11.37Mageia-1.mga8 <<>> ANY mageia.org
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 51375
;; flags: qr rd ra; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;mageia.org.                    IN      ANY

;; ANSWER SECTION:
mageia.org.             1605    IN      AAAA    2001:bc8:628:1f00::1
mageia.org.             1471    IN      MX      10 sucuk.mageia.org.
mageia.org.             1471    IN      MX      20 neru.mageia.org.

;; Query time: 171 msec
;; SERVER: 2607:f2c0::1#53(2607:f2c0::1)
;; WHEN: Wed Aug 24 13:57:17 EDT 2022
;; MSG SIZE  rcvd: 110

[root@x3 ~]# dig ANY mageia.org
;; communications error to ::1#53: end of file
;; communications error to ::1#53: end of file

It's not a consistent error though.
Comment 18 Dave Hodgins 2022-08-24 20:14:33 CEST
Most of the time when it fails, dig simply does not return an answer section
or any error message.
# dig ANY mageia.org

; <<>> DiG 9.11.37Mageia-1.mga8 <<>> ANY mageia.org
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 25116
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
;; QUESTION SECTION:
;mageia.org.                    IN      ANY

;; Query time: 0 msec
;; SERVER: ::1#53(::1)
;; WHEN: Wed Aug 24 14:10:38 EDT 2022
;; MSG SIZE  rcvd: 39

After stopping unbound.service and starting named.service, I consistently get
the answer section returned with
;; ANSWER SECTION:
mageia.org.             1793    IN      MX      10 sucuk.mageia.org.
mageia.org.             1793    IN      MX      20 neru.mageia.org.
mageia.org.             1793    IN      SOA     ns0.mageia.org. root.mageia.org. 2022071601 7200 3600 86400 300
mageia.org.             1793    IN      AAAA    2001:bc8:628:1f00::1
mageia.org.             1793    IN      A       163.172.148.228
mageia.org.             1793    IN      NS      ns1.mageia.org.
mageia.org.             1793    IN      NS      ns0.mageia.org.
Comment 19 christian barranco 2022-08-24 20:35:31 CEST
I was too much focusing on making sure localhost is the server use to resolve the query…. 
Indeed, the query is not successful. 
Are you using the unbound.conf shipped with the package or your own version?
Do you get the same results with current version of unbound, 1.13.0?

It works well on my side but I have tweaked the unbound.conf to my taste.
Comment 20 Dave Hodgins 2022-08-24 21:42:57 CEST
I'd never installed unbound prior to installing the testing version, and
didn't make any configuration changes prior to starting the unbound.service

I'll test the prior version of unbound shortly.
Comment 21 Dave Hodgins 2022-08-24 21:55:49 CEST
Uninstalled the testing version, deleted /etc/unbound.
Installed the release version.
[root@x3 ~]# rpm -q unbound
unbound-1.13.0-2.mga8
[root@x3 ~]# systemctl stop named.service
[root@x3 ~]# systemctl start unbound.service 
[root@x3 ~]# dig ANY mageia.org
;; communications error to 2607:f2c0::1#53: connection reset

After that dig ANY mageia.org consistently returns
;; ANSWER SECTION:
mageia.org.             1717    IN      A       163.172.148.228
mageia.org.             1717    IN      AAAA    2001:bc8:628:1f00::1
mageia.org.             1717    IN      SOA     ns0.mageia.org. root.mageia.org. 2022071601 7200 3600 86400 300
mageia.org.             1717    IN      NS      ns1.mageia.org.
mageia.org.             1717    IN      NS      ns0.mageia.org.
mageia.org.             1717    IN      MX      20 neru.mageia.org.
mageia.org.             1717    IN      MX      10 sucuk.mageia.org.

So while the first failure doesn't look good, the inconsistency is a regression
in the updates testing version.
Comment 22 christian barranco 2022-08-24 22:00:41 CEST
Thanks Dave. I will have a look at the configuration file this weekend. 
In your test with the current version, what is the server information you get after getting mageia.org resolved?
Comment 23 Dave Hodgins 2022-08-24 22:04:00 CEST
Ah. Not a regression.
# dig ANY google.com

; <<>> DiG 9.11.37Mageia-1.mga8 <<>> ANY google.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 34138
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
;; QUESTION SECTION:
;google.com.                    IN      ANY

;; Query time: 0 msec
;; SERVER: ::1#53(::1)
;; WHEN: Wed Aug 24 16:03:02 EDT 2022
;; MSG SIZE  rcvd: 39
Comment 24 Dave Hodgins 2022-08-24 22:10:03 CEST
Looks like it's just dig that has problems. Both host and nslookup are working
properly with both the release and updates testing versions of unbound.
Comment 25 Dave Hodgins 2022-08-24 22:12:04 CEST
Back with the updates testing version of unbound ...
[root@x3 ~]# host ody.ca      
ody.ca has address 216.240.0.3
ody.ca mail is handled by 5 mgw.ody.ca.
[root@x3 ~]# dig ody.ca

; <<>> DiG 9.11.37Mageia-1.mga8 <<>> ody.ca
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 34321
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
;; QUESTION SECTION:
;ody.ca.                                IN      A

;; Query time: 0 msec
;; SERVER: ::1#53(::1)
;; WHEN: Wed Aug 24 16:10:49 EDT 2022
;; MSG SIZE  rcvd: 35

So even though dig is failing to return answers, normal dns usage is working.
Comment 26 Dave Hodgins 2022-08-24 22:13:34 CEST
As it's not a regression and normal usage is working, I'm inclined to ok the
update. Ok with you Christian or do you see a way to fix the dig usage.
Comment 27 christian barranco 2022-08-24 22:17:57 CEST
Hi Dave. I agree to validate it. 
I will dig more into the dig issue though :)
and I will update the package if it is related to the configuration file we ship. 
Thanks for your support.
Comment 28 christian barranco 2022-08-24 22:36:15 CEST
Could you comment out the last block of /etc/unbound.conf , restart unbound service and retest ?

Block to comment out:
#forward-zone:
#   name: "."
#   forward-addr: 127.0.0.1@40
#   forward-addr: 127.0.0.1@41
Comment 29 christian barranco 2022-08-24 22:58:25 CEST
I just looked at Fedora and openSUSE spec and configuration files. They go beyond us to configure unbound. They set the root server list up, for instance. We could also activate DNSSEC. 
I’d like to suggest we follow that path. However, as eatdirt is the official maintainer, I need his view on this first. 
In the meanwhile, as it is a security update, I propose we validate this update with the same configuration we havé been providing eg the in Testing.
Comment 30 Dave Hodgins 2022-08-25 00:15:03 CEST
Validating. We can do the config fixes which should fix dig in a future bugfix
update.

Advisory committed to svn.

Keywords: (none) => advisory, validated_update
Whiteboard: (none) => MGA8-64-OK
CC: (none) => sysadmin-bugs

Comment 31 Chris Denice 2022-08-25 11:57:54 CEST
I am back :)
Thanks for taking care of this!

For the config, we cannot satisfy everyone, I am using unbound everday on top of dnscrypt-proxy, so it does work.

Any specific usage will require the configuration to be edited, I do prefer to let this user-side.

Cheers,
Chris.
Comment 32 christian barranco 2022-08-25 12:10:52 CEST
Welcome back Chris !

Ok. Got you. 
Quick question : what is purpose to have the following forward-zone set into the conf file we provide?

forward-zone:
   name: "."
   forward-addr: 127.0.0.1@40
   forward-addr: 127.0.0.1@41
Comment 33 Chris Denice 2022-08-25 14:05:57 CEST
This matches the listen addresses of dnscrypt-proxy, so it you install both packages, dns encryption works out of the box!
Comment 34 christian barranco 2022-08-25 19:37:39 CEST
Could it confuse dig sometimes to time?
I have not seen yet this configuration with other distributions. Shouldn’t it be a user specific configuration, up then to the user to set?
Comment 35 Dave Hodgins 2022-08-25 21:39:06 CEST
From systemctl status unbound.service
Loaded: loaded (/usr/lib/systemd/system/unbound.service; disabled; vendor preset: disabled)

After installation the user is supposed to ensure the configuration is the
way they want it, before enabling and/or starting the service.
Comment 36 Mageia Robot 2022-08-25 23:23:08 CEST
An update for this issue has been pushed to the Mageia Updates repository.

https://advisories.mageia.org/MGASA-2022-0303.html

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


Note You need to log in before you can comment on or make changes to this bug.