This bug is a followup to this mail thread:

Le 26/06/2023 à 14:13, Raphaël G. a écrit :
Hi Guillaume,

Le lun., juin 26, 2023 à 12:18, Guillaume Rousse
<guillomovitch@gmail.com> a écrit:

Le 26/06/2023 à 09:42, rapsys a écrit :

rapsys <rapsys> 2.10.3-15.mga9:
+ Revision: 1963120
- Fix tmpfiles
Fix naming type in config
Switch to local socket

This is not the first time you're touching this package, without any
attempt to discuss changes with the maintainer first. Should I ask for
your commit bit removal for you to learn to work with other people
rather than in total isolation ?

You are right, I only thought I losted my changed and didn't saw your revert
between commit 1661218 and 1661219 the 2020-12-19.

From what I see you applied these changes since then:
- unexisting /sbin/false shell (only /bin/false exists)
- post/preun scripts invalid service name
- readability on %{_sysconfdir}/%{name}/keys to be able to list files as
used and edit them with sudo
- change default rsa key from 1024 bits to 2048 (I had changed it to 4096)
- made sure we have default keys generated

Three of my "improvement attemps" didn't make it eventually:
- set in sign+verify mode by default (may be a good idea, or not)
- use local socket instead of open port (like in opendmarc)
- systemd-tmpfiles creating pid, local socket and setting ownership to
opendkim (like in opendmarc)
- improvement in README.urpmi documentation file (like in opendmarc)

Why is it preferable to keep an open port where everyone may write over
a local socket owned by opendkim user ?
(Open port example is commented to allow anybody to quickly set it up if
needed)

Default keys are generated now, is it such a bad idea to afford a
sign+verify mode by default ?
It prevent the usual mistake of forgeting it in verification only mode
and to have valid signature it requires extra configuration anyway.

Sorry for the tab vs space mess, I understand it don't help my position.

I clearly did a mistakes by assigning user ownership on
/etc/opendkim/{SigningTable,KeyTable,TrustedHosts} files and
/etc/opendkim/keys directory, sorry again.

My goal was only to have opendkim coherent with opendmarc configuration,
avoid opening a local port when a local socket is enough and have
minimal postfix configuration to get it working.

I can revert tabs vs space mess if it's the only point bothering you.

No, that's not my only concern.

You're confusing your own preferences as a system administrator, and
your role as a packager. Using a local socket instead of a network port,
for instance, doesn't match any kind of distribution-wide policy, and
enforcing it by default is clearly out of packaging scope. Let sysadmin
read upstream documentation, and decide what fit their own needs,
instead of supposing you're in a better position to do it.

Please revert all your changes to the default upstream configuration
file, unless they match a a well-established policy, such as FHS
enforcement, or consistent file permissions scheme. Or consider writing
such a policy, and submit a draft it for discussion first.

I took the time to limit to the changes to the strict minimum in revision 1963815 available as opendkim-2.10.3-18.mga9 in updates_testing.

Diff since your last change in revision 1841496 available in next attachment.

Created attachment 13917 [details]
Improvements to validate

My only intend is to have a package which is a great tool, with ease to setup it and certainly not a debian like vanilla build without added value.

I see no other possible usage for opendkim appart:
- verify mail signature at reception
- add mail signature at emission (modulo keys generation, configuration and dns zone)

I found no distribution-wide policy which suggests or requires to use a network port instead of socket, clearly provide both choice with network port commented out is not out of packaging scope.

The only applicable guideline I found regarding this concerns is our distribution general goal:
« Beyond just delivering a secure, stable and sustainable operating system, the goal is also to become and maintain a credible and recognized community in the free software world. »
https://www.mageia.org/en/about/

You didn't suggested that an user owned local socket instead of an open port is less secure, so what is the problem ?

People with an open port configuration will keep it as config file will not be replaced.

People installing it fresh will get the new configuration and README.urpmi paving the way to get it working with ease.

Clearly the mageia goal remind us we build package for people, not provide vanilla package as is and ask them to read tons of documentation where only few lines will be usefull to them :
« Our mission: to build great tools for people. »
https://www.mageia.org/en/about/

The only point I endorse is the nice idea that we could have a packaging guideline for network server packages (configuration, pid, directory permissions, etc).

I don't think it's a valid reason to block these improvements.

This time I took the time to double check everything in the hope that we will not stay stuck like it happened for mga8 two years ago...

Raphael is rapsys. who has done a lot of recent changes to this, for which Guillaume is the registered maintainer, hence assigning the bug to you.
Comment 1 sets the context. Clearly a lot of dialogue has been aired.

Assignee: bugsquad => guillomovitch
Summary: Postfix easy integration, useless sysconfig file, non traversable dirs, unclear doc and duplicate definition of opendkim-default-keygen => opendkim: no Postfix easy integration, useless sysconfig file, non traversable dirs, unclear doc and duplicate definition of opendkim-default-keygen

The package should be kept as close a possible to what upstream provides,
partly to ensure people coming from other distributions find the same thing,
but mostly to simplify updating to new versions. What Mageia provides should
not be customized to one packagers preferences.

Using a network port instead of a socket is required for postfix to provide
services for multiple systems in a lan.

As for tools to automatically configure it for various use cases, that should
be done in mcc.

CC: (none) => davidwhodgins

(In reply to Raphael Gertz from comment #0)
> Opendkim's systemd service miss an ExecStartPost directive to allow updating
> it's socket file permission to be usefull by postfix.
> 

For the record, there isn't any need to call systemd-tmpfiles in systemd .service file ExecStartPost.

https://svnweb.mageia.org/packages/cauldron/opendkim/current/SPECS/opendkim.spec?revision=1963811&view=markup#l72

'systemd-tmpfiles --create' is called via rpm filetrigger scriptlet in systemd package if files are installed into /usr/lib/tmpfiles.d/

Filetriggers can be checked with:
$ rpm -q --filetriggers systemd

(In reply to Jani Välimaa from comment #7)
> (In reply to Raphael Gertz from comment #0)
> > Opendkim's systemd service miss an ExecStartPost directive to allow updating
> > it's socket file permission to be usefull by postfix.
> > 
> 
> For the record, there isn't any need to call systemd-tmpfiles in systemd
> .service file ExecStartPost.
> 
> https://svnweb.mageia.org/packages/cauldron/opendkim/current/SPECS/opendkim.
> spec?revision=1963811&view=markup#l72
> 
> 'systemd-tmpfiles --create' is called via rpm filetrigger scriptlet in
> systemd package if files are installed into /usr/lib/tmpfiles.d/
> 
> Filetriggers can be checked with:
> $ rpm -q --filetriggers systemd

There is a need when you use a file socket, the group ownership is then changed to postfix, allowing it to write to the socket.

There is no need indeed if you want to complicate life of people using a file socket placed in chroot...

(In reply to Raphael Gertz from comment #8)
> (In reply to Jani Välimaa from comment #7)
> > (In reply to Raphael Gertz from comment #0)
> > > Opendkim's systemd service miss an ExecStartPost directive to allow updating
> > > it's socket file permission to be usefull by postfix.
> > > 
> > 
> > For the record, there isn't any need to call systemd-tmpfiles in systemd
> > .service file ExecStartPost.
> > 
> > https://svnweb.mageia.org/packages/cauldron/opendkim/current/SPECS/opendkim.
> > spec?revision=1963811&view=markup#l72
> > 
> > 'systemd-tmpfiles --create' is called via rpm filetrigger scriptlet in
> > systemd package if files are installed into /usr/lib/tmpfiles.d/
> > 
> > Filetriggers can be checked with:
> > $ rpm -q --filetriggers systemd
> 
> There is a need when you use a file socket, the group ownership is then
> changed to postfix, allowing it to write to the socket.
> 
> There is no need indeed if you want to complicate life of people using a
> file socket placed in chroot...

One should add at least a comment and reasoning to .spec or patches if there are some special cases or needs to alter the upstream .provided files. Normal way to handle tmpfiles is to rely on rpm filetriggers instead of creating tmpfiles while starting the .service.

Isn't there something wrong in configuration or code creating the socket if its ownership needs to be altered after the creation?

It's impossible to review such a bunch of changes at once: just trying to identify differences between release 2.10.3-14.mga9 and 2.10.3-15.mga9 is 389 lines, whom at least half of them are purely cosmetics, such as spaces converted to tabulations, and strings replaced with rpm macros...

And we're way too late in the distribution release cycle: we're supposed to fix bugs, not to apply personal preferences gratuitously.

That's abusive behaviour, not collaboration.

(In reply to Guillaume Rousse from comment #10)
> It's impossible to review such a bunch of changes at once: just trying to
> identify differences between release 2.10.3-14.mga9 and 2.10.3-15.mga9 is
> 389 lines, whom at least half of them are purely cosmetics, such as spaces
> converted to tabulations, and strings replaced with rpm macros...
> 

You may review the attached patch 13917 which do a svn diff between your last commit and current state which show only the changes.

https://bugs.mageia.org/attachment.cgi?id=13917&action=diff

> And we're way too late in the distribution release cycle: we're supposed to
> fix bugs, not to apply personal preferences gratuitously.
> 

Didn't you already used that last time before mageia 8 was released, I run with my changes in production since then, it cancel this point imao.

Situation has changed for Mageia 9, from what Mika said on the dev ml asking how setup dkim/dmarc/spf, gmail seems to require spf/dkim/dmarc feature now.

Didn't had time to look into it, even with spf/dkim/dmarc my first mail finish in spam anyway:
https://developers.google.com/gmail/ampemail/security-requirements?hl=en

I have my own opinion, and will not comment on it, about what I think is uncollaborative, abusive behaviour, bad faith, excuses and fake complaining, please drop that.

(In reply to Jani Välimaa from comment #9)
> One should add at least a comment and reasoning to .spec or patches if there
> are some special cases or needs to alter the upstream .provided files.
> Normal way to handle tmpfiles is to rely on rpm filetriggers instead of
> creating tmpfiles while starting the .service.
> 

The idea of using systemd tmpfils was to take advantage it's feature to change file ownership and permissions as it runs with root privileges.

This allows to keep opendkim as simple user.

I was under the impression that triggering a file permission refresh on opendkim service start/restart was acceptable cost even if someone use network port configuration to give an easy way to have sock feature.

> Isn't there something wrong in configuration or code creating the socket if
> its ownership needs to be altered after the creation?
> 

Using the UserID opendkim:postfix + Umask 002 required opendkim process to start as root I think which seems a bad idea.

I'm fed up with useless bikeshiding. I resigned as package maintainer, feel free to take over maintainership.

Assignee: guillomovitch => bugsquad

I have no idea about this, but i see is is not progressing.

Assigning all packagers to see of someone want to take the steering wheel

CC: (none) => bugsquad, fri
Assignee: bugsquad => pkg-bugs

(In reply to Morgan Leijström from comment #14)
> I have no idea about this, but i see is is not progressing.
> 
> Assigning all packagers to see of someone want to take the steering wheel

Like I answered in private to Lewis, I have to redo for the 3rd time the same work, with little to no hope to get the configuration change approved as update, as it's against guidelines...

I will do the job as soon as I have time and brain to do it.

Hopefully this time it will get approved...

Assigning to you then :)

Assignee: pkg-bugs => mageia

(In reply to Morgan Leijström from comment #16)
> Assigning to you then :)

Fix done, like for cauldron, hopefully it will make it :)

(In reply to Raphael Gertz from comment #19)
> Advisory commited under number 32468.

bug 32468 seems to be a security bug, I don't have access to it.

CC: (none) => marja11

(In reply to Marja Van Waes from comment #20)
> 
> (In reply to Raphael Gertz from comment #19)
> > Advisory commited under number 32468.
> 
> bug 32468 seems to be a security bug, I don't have access to it.

Advisory commited under number 32089, my bad, I did a mistake in numbering, now corrected.

Changing "Version:" to "9", because it is obvious that this report is no longer about cauldron.

Version: Cauldron => 9

(In reply to Marja Van Waes from comment #22)
> Changing "Version:" to "9", because it is obvious that this report is no
> longer about cauldron.

There are still issues with cauldron though...

Here, following the steps in README.urpmi :
# chmod 0640 /etc/opendkim/keys/default.private
# chmod 0644 /etc/opendkim/keys/default.txt 
# opendkim-testkey
opendkim-testkey: /etc/opendkim/keys/default.private: WARNING: unsafe permissions

This results in failures not indicating what is wrong anywhere !
postfix/cleanup[26837]: 1AA5F1A11AE: milter-reject: END-OF-MESSAGE from hostname[127.0.0.1]: 4.7.1 Service unavailable - try again later;

Apparently 600 is required for the default.private file now.
# chown opendkim /etc/opendkim/keys/default.{private,txt}
# chmod 0600 /etc/opendkim/keys/default.private
# opendkim-testkey

And the mail can be finally sent.

CC: (none) => guillaume.bedot

(In reply to Guillaume Bedot from comment #23)
> (In reply to Marja Van Waes from comment #22)
> > Changing "Version:" to "9", because it is obvious that this report is no
> > longer about cauldron.
> 
> There are still issues with cauldron though...

May you provide your configuration plz:
- grep 'milter' /etc/postfix/main.cf
- grep -vE '^(#|$)' /etc/opendkim.conf

> Apparently 600 is required for the default.private file now.
> # chown opendkim /etc/opendkim/keys/default.{private,txt}
> # chmod 0600 /etc/opendkim/keys/default.private
> # opendkim-testkey
> 
> And the mail can be finally sent.

I will look into it.

I don't understand how it's a good idea and secure to give opendkim write permission to the key files.

(In reply to Guillaume Bedot from comment #23)
> Here, following the steps in README.urpmi :
> # chmod 0640 /etc/opendkim/keys/default.private
> # chmod 0644 /etc/opendkim/keys/default.txt 
> # opendkim-testkey
> opendkim-testkey: /etc/opendkim/keys/default.private: WARNING: unsafe
> permissions

I tested myself, even with this warning, the service start.

The program opendkim-testkey seems to have an extra bug, if you setup opendkim to sign for a domain, set the default key + private, it issue a message "opendkim-testkey: key not secure" in extra of the warning.

I double checked that my domain is dnssec signed...

I suspect the problem may comes from somewhere else.

Please provide as well:
$ rpm -qa | grep opendkim

(In reply to Guillaume Bedot from comment #23)
> This results in failures not indicating what is wrong anywhere !
> postfix/cleanup[26837]: 1AA5F1A11AE: milter-reject: END-OF-MESSAGE from
> hostname[127.0.0.1]: 4.7.1 Service unavailable - try again later;

Set in /etc/opendkim.conf:
LogWhy yes

« This causes a large increase in the amount of log data generated for each message, so it should be limited to debugging use and not enabled for general operation. »

By any chance, did you uncomment RequireSafeKeys which default as yes in /etc/opendkim.conf but is set to false in source code ?

Oh sorry Raphael, I didn't realize I used my old email for this bug :/

# grep 'milter' /etc/postfix/main.cf
non_smtpd_milters       = unix:run/opendkim/opendkim.sock
smtpd_milters           = unix:run/opendkim/opendkim.sock
milter_default_action   = accept

(because of postfix chroot, i use relative paths for it to be clearer)

# grep -vE '^(#|$)' /etc/opendkim.conf
Canonicalization	relaxed/relaxed
Domain			geex.ovh
ExternalIgnoreList	refile:/etc/opendkim/external_hosts.conf
InternalHosts		refile:/etc/opendkim/internal_hosts.conf
KeyFile			/etc/opendkim/keys/default.private
KeyTable		/etc/opendkim/key_table.conf
OverSignHeaders		From
PidFile		/run/opendkim/opendkim.pid
Selector		default
SigningTable		refile:/etc/opendkim/signing_table.conf
Socket			local:/var/spool/postfix/run/opendkim/opendkim.sock
SubDomains yes
SyslogSuccess yes
UMask			002
UserID opendkim:postfix

I tried the group thing various ways, that's why the not default Umask, and postfix group

# rpm -qa | grep opendkim
lib64opendkim11-2.11.0-0.beta2.2.mga10
opendkim-2.11.0-0.beta2.2.mga10

About SafeKeys, no:
# grep Safe /etc/opendkim.conf
##  RequireSafeKeys { yes | no }
# RequireSafeKeys	Yes

And good to know about the LogWhy key.

Again sorry for replying so late.

Finally,

@Guillaume Rousse:
I understand how it may be more flexible to use network sockets, but what's the real use case, I'd use localhost access only directly only the host or postfix and opendkim in the same container anyway. A distribution is about easy to use software and safe defaults settings. Maybe I'm missing something ?

CC: (none) => geex+mageia

> I don't understand how it's a good idea and secure to give opendkim write
> permission to the key files.

I haven't tried 400, but I don't why it shouldn't work

(In reply to Guillaume Bedot from comment #28)
> Oh sorry Raphael, I didn't realize I used my old email for this bug :/
> 
> # grep 'milter' /etc/postfix/main.cf
> non_smtpd_milters       = unix:run/opendkim/opendkim.sock
> smtpd_milters           = unix:run/opendkim/opendkim.sock
> milter_default_action   = accept
> 
> (because of postfix chroot, i use relative paths for it to be clearer)

If postfix is chrooted like on my configuration, have absolute path /run/opendkim/opendkim.sock works too, relative path changes nothing here...

> # grep -vE '^(#|$)' /etc/opendkim.conf
> Canonicalization	relaxed/relaxed
> Domain			geex.ovh
> ExternalIgnoreList	refile:/etc/opendkim/external_hosts.conf
> InternalHosts		refile:/etc/opendkim/internal_hosts.conf
> KeyFile			/etc/opendkim/keys/default.private
> KeyTable		/etc/opendkim/key_table.conf
> OverSignHeaders		From
> PidFile		/run/opendkim/opendkim.pid
> Selector		default
> SigningTable		refile:/etc/opendkim/signing_table.conf
> Socket			local:/var/spool/postfix/run/opendkim/opendkim.sock
> SubDomains yes
> SyslogSuccess yes
> UMask			002
> UserID opendkim:postfix

You use KeyTable and SigningTable, so KeyFile is ignored, you may as well comment it ;)

See /etc/opendkim.conf file: « [KeyFile] Ignored if SigningTable and KeyTable are used. »

I think your problem is with the UserID and UMask line tricks, which I wanted gone for good reason, try with these line commented out/removed.

I changed the opendkim.service to fix the permissions and ownership of /var/spool/postfix/run/opendkim/opendkim.sock after startup using a smart systemd tmpfiles config file.

Magic happens in /usr/lib/tmpfiles.d/opendkim.conf (opendkim.sock line) and /usr/lib/systemd/system/opendkim.service (see ExecStartPost).

The root problem with opendkim is that opendkim-testkey don't use the same source code to check files permission that is used in the opendkim daemon...

> I tried the group thing various ways, that's why the not default Umask, and
> postfix group

Seems like a situation, if confirmed, where KISS is better now :)

I think in your case the process fails to start on the postfix group change attempt after systemd already dropped it's privileges to opendkim:opendkim.

Just to be sure if it don't works:
ls -l /etc/opendkim/signing_table.conf /etc/opendkim/key_table.conf

> @Guillaume Rousse:
> I understand how it may be more flexible to use network sockets, but what's
> the real use case, I'd use localhost access only directly only the host or
> postfix and opendkim in the same container anyway. A distribution is about
> easy to use software and safe defaults settings. Maybe I'm missing something
> ?

Is it really useful to dig up the hatchet of bad faith again ?

(In reply to Raphael Gertz from comment #30)
> If postfix is chrooted like on my configuration, have absolute path
> /run/opendkim/opendkim.sock works too, relative path changes nothing here...
It's a very personal trick that could not even work.

> You use KeyTable and SigningTable, so KeyFile is ignored, you may as well
> comment it ;)
> 
> See /etc/opendkim.conf file: « [KeyFile] Ignored if SigningTable and
> KeyTable are used. »
Missed that.
 
> I think your problem is with the UserID and UMask line tricks, which I
> wanted gone for good reason, try with these line commented out/removed.
I'll clean this all and simulate a first install.

> I changed the opendkim.service to fix the permissions and ownership of
> /var/spool/postfix/run/opendkim/opendkim.sock after startup using a smart
> systemd tmpfiles config file.
> 
> Magic happens in /usr/lib/tmpfiles.d/opendkim.conf (opendkim.sock line) and
> /usr/lib/systemd/system/opendkim.service (see ExecStartPost).
[...] 
> Seems like a situation, if confirmed, where KISS is better now :)
For first installs, it may be a progress, now let's make sure the update path is not too messy...

> Is it really useful to dig up the hatchet of bad faith again ?
Sorry I didn't want to add fuel to the fire and it's not a place for personal chat

I can't reproduce my issue now ?!
I begin to think I messed up something trying to fix my issue, but maybe at first it was just because the domain was set to example.com after the update, and my configuration in /etc/opendkim.conf.rpmsave ...

Or maybe this file was created when I tried a fresh install

I found that with my local ethernet ips and hostnames added in /etc/opendkim/internal_hosts.conf , I suddently can't connect to the socket anymore...
Better leave it empty.

nov. 28 09:39:38 x2.local postfix/submission/smtpd[10461]: warning: connect to Milter service unix:run/opendkim/opendkim.sock: Permission denied

This software is weird.

Seems like you have a opendkim.service startup problem.

Did you check what is said in log ?

# systemctl status opendkim.service

# journalctl -u opendkim

If needed to troubleshoot, you may start it manualy with

# sudo -u opendkim strace /usr/sbin/opendkim 2> trace.log

So basicaly it works ? You may add a MGA-64-OK ?

This really weird. After the re-installation, it began working with the rights of the README.urpmi, I re-added all the bits of the previous config, one by one (the only change left is the location of the key, in a subfolder), it still works. 

nov. 28 15:46:43 x2.local opendkim[31586]: 5B4001A0228: DKIM-Signature field added (s=default, d=geex.ovh)

I tried with 777, it triggers the error (and 400/opendkim:opendkim does work by the way).

It works for me, now. I don't what happened.

I noticed that when there's no signing table match, with reject policy, the mail is sent anyway, but with the wildcard, it won't happen again.

I finally understood one of weird things with UMask at least : the 022 mask proposed in opendkim.conf misses the prefix 0 for octal, so one should use 18 or 0022 .

Anyway, the software doesn't seem very maintained, why don't we give one of the alternatives a try, maybe dkimpy ? https://launchpad.net/dkimpy-milter

@rapsys
For the record, i've taken a look at the opendkim.spec and i haven't seen something so awful since I wrote one for mame to permit updates without changing it...

Create files and put it as sources please, at least.

(In reply to Guillaume Bedot from comment #37)
> I finally understood one of weird things with UMask at least : the 022 mask
> proposed in opendkim.conf misses the prefix 0 for octal, so one should use
> 18 or 0022.

I will keep it commented, but I fixed commented out default value to 0022 just in case.

> Anyway, the software doesn't seem very maintained, why don't we give one of
> the alternatives a try, maybe dkimpy ? https://launchpad.net/dkimpy-milter

Opendkim just works, no real CVE since a long time and integration with postfix is kind of simple.

Feel free to package it and add an extra possibility for everyone.

Grass seems always greener somewhere else ;)

(In reply to Guillaume Bedot from comment #38)
> Create files and put it as sources please, at least.

In the 3 tries to improve this package, it may have been the case at some point and lost in one of the revert...

type: bugfix
subject: Fix opendkim default configuration, socket support, permissions and doc on Mga 9
src:
  9:
   core:
     - opendkim-2.10.3-17.mga9
description: |
  OpenDKIM usefull changes reported since mga8 were not included in Mageia 9.

  That caused our opendkim to lack socket support, have hard to maintain
  custom config not signing by default and impractical default permissions.

  Users with old configuration will keep it until they migrate, while fresh
  install will get new default configuration.

  These change will make life easier for our end users who just want to sign
  mails to get them accepted by various major mail providers requiring it.

  Changelog:
    - Fix bug 32089
    - Set service to fix socket permission on post start
    - Use upstream default config file
    - Fix README.urpmi to be readable
    - Fix tmpfile.d config to allow socket
    - Set keys directory as traversable
    - Switch to new configuration file schema
    - Remove duplicated include of opendkim-default-keygen
    - README.urpmi, tmpfiles and config files as source files

references:
 - https://bugs.mageia.org/show_bug.cgi?id=32089

Updated packages in core/updates_testing:
========================
lib(64)opendkim10-2.10.3-17.mga9.x86_64.rpm
lib(64)opendkim-devel-2.10.3-17.mga9.x86_64.rpm
opendkim-2.10.3-17.mga9.x86_64.rpm

from SRPM:
opendkim-2.10.3-17.mga9.src.rpm

@ Raphael Gertz you are reporter and packager the QA team can assume you test you own work and it works now ?

(In reply to katnatek from comment #43)
> @ Raphael Gertz you are reporter and packager the QA team can assume you
> test you own work and it works now ?

It works, I have it in production on a dedicated server...

Validating

CC: (none) => sysadmin-bugs
Keywords: (none) => validated_update
Whiteboard: (none) => MGA9-64-OK

(In reply to katnatek from comment #45)
> Validating

Thank's, finaly

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

https://advisories.mageia.org/MGAA-2024-0056.html

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