[MDEV-22638] Provide updateinfo.xml repository info for yum / dnf Created: 2020-05-19  Updated: 2023-11-27  Resolved: 2021-04-09

Status: Closed
Project: MariaDB Server
Component/s: Platform RedHat, Platform SUSE, Upgrades
Fix Version/s: N/A

Type: Task Priority: Major
Reporter: Hartmut Holzgraefe Assignee: Alexey Bychko (Inactive)
Resolution: Fixed Votes: 0
Labels: None

Attachments: XML File MariaDB-updateinfo-EXAMPLE.xml     XML File updateinfo.xml    

 Description   

yum / dnf package managers can provide information about available package updates if an updateinfo.xml information file is available in a yum repository, and it is also possible to filter the retrieved information to eg. show only "security" or "CVE" related updates.

Feature request: provide such updateinfo information in MariaDB yum/dnf repositories.



 Comments   
Comment by Sergei Golubchik [ 2020-06-09 ]

It won't make any practical difference. Currently we release quarterly, after Oracle CPU. That is every MariaDB release is a security release.

It can happen that MariaDB-server contains, for example, security fixes, but MariaDB-client, for example, doesn't. And MariaDB-common, basically, never does. But because of inter-package dependencies one cannot update just the server anyway.

In other words if one will filter to show only "security" or "CVE" releases it will still show all releases.

Comment by Hartmut Holzgraefe [ 2020-07-08 ]

But if we don't add the information then

yum updateinfo list updates --security

would never include MariaDB packages in its output, and user may be under false impression that there's no need to upgrade MariaDB as it is still fine security wise.

Comment by Hartmut Holzgraefe [ 2020-08-25 ]

Current status is "need feedback", but I'm not sure feedback from whom it is waiting for?

Comment by Alexey Bychko (Inactive) [ 2021-04-01 ]

need to try then. who will be maintaining the list of fixed issues?

Comment by Sergei Golubchik [ 2021-04-01 ]

it seems (I can be wrong) that it doesn't need a complete list of fixed issues, it could just have one issue "fixed security issues", with the reference url https://mariadb.com/kb/en/library/security/, marked as security release in metadata. That should be enough for yum/dnf to list it as a "security relevant upgrade"

Comment by Alexey Bychko (Inactive) [ 2021-04-02 ]

script example: https://github.com/vmfarms/generate_updateinfo

Comment by Alexey Bychko (Inactive) [ 2021-04-05 ]

seems centos doesn't support yum-security plugin to list the CVE's

Comment by Alexey Bychko (Inactive) [ 2021-04-05 ]

schema for updateinfo https://github.com/openSUSE/libzypp/blob/master/zypp/parser/yum/schema/updateinfo.rnc

Comment by Alexey Bychko (Inactive) [ 2021-04-05 ]

from my side i see no way to simply generate the updateinfo . we need to have the list of issues, links to jira and so on. I will attach examples. from my side it's wontfix, but serg may have another view

Comment by Sergei Golubchik [ 2021-04-05 ]

This — updateinfo.xml — is an example of a real updateinfo.xml from Scientific Linux.

Something remotely similar for our repos could look like

<?xml version="1.0"?>
<?xml-stylesheet type="text/xsl" href="updateinfo.xsl"?>
<updates>
  <update from="maria-developers@mariadb.org" status="final" type="security" version="2.0">
    <id>MariaDB-10.4.21</id>
    <title>MariaDB Server 10.4 release</title>
    <description>MariaDB Server 10.4 release</description>
    <severity>moderate</severity>
    <release>MariaDB Server 10.4</release>
    <issued date="2021-10-20 00:00:00"/>
    <pkglist>
      <collection short="MariaDB-10.4.21">
        <name>MariaDB Server 10.4</name>
        <package arch="x86_64" name="MariaDB-server" release="10.4.21-1_el7" src="MariaDB-10.4.21-1.el7.src.rpm" version="10.4.21">
          <filename>MariaDB-server-10.4.21-1.el7.x86_64.rpm</filename>
          <sum type="sha256">d87d08920dc0d6fc8115db1658235f5de735757dd37422431369a61fa249bc82</sum>
        </package>
        <!-- ... etc ... -->
      </collection>
    </pkglist>
    <references>
      <reference href="https://mariadb.com/kb/en/mariadb-10421-release-notes/" id="mariadb-10421-relnotes" title="Issues fixed in MariaDB 10.4.21" type="self"/>
      <reference href="https://https://mariadb.com/kb/en/library/security/" id="" title="List of CVEs fixed in MariaDB" type="other"/>
    </references>
  </update>
</updates>

Comment by Alexey Bychko (Inactive) [ 2021-04-06 ]

the RH way to generate updateinfo is:

1 - generate errata.xml with issues, links to bugzilla, etc
2 - generate updateinfo from that errata.xml
3 - update repository metadata with that updateinfo

but we have no errata.xml, so we may try to generate simplified updateinfo with some predefined values and some missing values in hope it will work.
from my understanding it should be some script to run, not manual editing.

Comment by Alexey Bychko (Inactive) [ 2021-04-06 ]

seems RH schema is not the same as Suse

Comment by Alexey Bychko (Inactive) [ 2021-04-06 ]

I'm not sure that Scientific linux example is a really example for RHEL/Centos and SLES. EPEL updateinfo differs in details.

serg <package src=...> attribute is a name of src.rpm in your example and full URL to downloadable package in RHEL/Fedora/Centos.
For ES it's impossible to get URL to package because it has a token as part of URL. we can process some xml template dynamically in case it's required. for now I will set src.rpm to src attribute

Comment by Alexey Bychko (Inactive) [ 2021-04-06 ]

ok, seems it works for me at least on centos-7.

#yum list --security
 
Available Packages
MariaDB-backup.x86_64                                                                                    10.4.18_11-1.el7_9                                                                       mariadb-es-main
MariaDB-backup-debuginfo.x86_64                                                                          10.4.18_11-1.el7_9                                                                       mariadb-es-main
MariaDB-client.x86_64                                                                                    10.4.18_11-1.el7_9                                                                       mariadb-es-main
MariaDB-client-debuginfo.x86_64                                                                          10.4.18_11-1.el7_9                                                                       mariadb-es-main
MariaDB-columnstore-engine.x86_64                                                                        10.4.18_11-1.el7_9                                                                       mariadb-es-main
MariaDB-columnstore-engine-debuginfo.x86_64                                                              10.4.18_11-1.el7_9                                                                       mariadb-es-main
MariaDB-columnstore-libs.x86_64                                                                          10.4.18_11-1.el7_9                                                                       mariadb-es-main
MariaDB-columnstore-libs-debuginfo.x86_64                                                                10.4.18_11-1.el7_9                                                                       mariadb-es-main
MariaDB-columnstore-platform.x86_64                                                                      10.4.18_11-1.el7_9                                                                       mariadb-es-main
MariaDB-columnstore-platform-debuginfo.x86_64                                                            10.4.18_11-1.el7_9                                                                       mariadb-es-main
MariaDB-common.x86_64                                                                                    10.4.18_11-1.el7_9                                                                       mariadb-es-main
MariaDB-common-debuginfo.x86_64                                                                          10.4.18_11-1.el7_9                                                                       mariadb-es-main
MariaDB-compat.x86_64                                                                                    10.4.18_11-1.el7_9                                                                       mariadb-es-main
MariaDB-cracklib-password-check.x86_64                                                                   10.4.18_11-1.el7_9                                                                       mariadb-es-main
MariaDB-cracklib-password-check-debuginfo.x86_64                                                         10.4.18_11-1.el7_9                                                                       mariadb-es-main
MariaDB-devel.x86_64                                                                                     10.4.18_11-1.el7_9                                                                       mariadb-es-main
MariaDB-devel-debuginfo.x86_64                                                                           10.4.18_11-1.el7_9                                                                       mariadb-es-main
MariaDB-gssapi-server.x86_64                                                                             10.4.18_11-1.el7_9                                                                       mariadb-es-main
MariaDB-gssapi-server-debuginfo.x86_64                                                                   10.4.18_11-1.el7_9                                                                       mariadb-es-main
MariaDB-hashicorp-key-management.x86_64                                                                  10.4.18_11-1.el7_9                                                                       mariadb-es-main
MariaDB-hashicorp-key-management-debuginfo.x86_64                                                        10.4.18_11-1.el7_9                                                                       mariadb-es-main
MariaDB-rocksdb-engine.x86_64                                                                            10.4.18_11-1.el7_9                                                                       mariadb-es-main
MariaDB-rocksdb-engine-debuginfo.x86_64                                                                  10.4.18_11-1.el7_9                                                                       mariadb-es-main
MariaDB-server.x86_64                                                                                    10.4.18_11-1.el7_9                                                                       mariadb-es-main
MariaDB-server-debuginfo.x86_64                                                                          10.4.18_11-1.el7_9                                                                       mariadb-es-main
MariaDB-shared.x86_64                                                                                    10.4.18_11-1.el7_9                                                                       mariadb-es-main
MariaDB-shared-debuginfo.x86_64                                                                          10.4.18_11-1.el7_9                                                                       mariadb-es-main

Comment by Alexey Bychko (Inactive) [ 2021-04-06 ]

first version is here https://github.com/mariadb-corporation/MariaDBE-CI/blob/ci-scripts/gen-updateinfo.sh
testing now, looks good so far

Comment by Alexey Bychko (Inactive) [ 2021-04-06 ]

dbart could you please test it on staging and let me know if it's OK or not?

  • you need to have rpm binary installed (deb/ubuntu version should also work)
  • call it on rpm tree like

     
    ./gen-updateinfo.sh --repository /srv/repo/sles/15/rpms --platform-name SLES --platform-version 15 --severity critical 
     modifyrepo /tmp/updateinfo.xml /srv/repo/sles/15/rpms/repodata
    

to check if added repo has properly built updateinfo:

SLES:  zypper lp -a | grep -i mariadb
RHEL: yum updateinfo list --security

Comment by Alexey Bychko (Inactive) [ 2021-04-06 ]

attached generated updateinfo

Comment by Daniel Bartholomew [ 2021-04-06 ]

Added updateinfo to the 10.5.9-6 staging repositories. Using the commands:

./gen-updateinfo.sh --repository /ds1819/mariadb-enterprise-server/10.5.9-6/rpm/rhel/8/x86_64/ --platform-name RedHat --platform-version 8
modifyrepo /tmp/updateinfo.xml /ds1819/mariadb-enterprise-server/10.5.9-6/rpm/rhel/8/x86_64/repodata

And repeated the above for RHEL 7, SLES 12, and SLES 15. I wasn't sure if "--platform-name" needed to be something specific so I just used "SLES" for SLES 12 and 15. I then uploaded the updated repositories to staging and force-synced them to the CDN.

To test I started up my RHEL 8 test VM and set up the ES repos with 10.5.8-5 and installed MariaDB-server and MariaDB-client. Then I switched to the newly updated 10.5.9-6 staging repositories and tested the `dnf updateinfo ...` command. If you'd like to do it yourself, here are the exact commands I ran (you'll need to set token to your token):

token="<my_token>"
repo="enterprise-release-helpers"
url_script="https://dlm.mariadb.com/${repo}/mariadb_es_repo_setup"
url_checksum="https://dlm.mariadb.com/${repo}/checksums/sha256sums.txt"
curl -sSLO ${url_script}
curl -LsS ${url_checksum} | sha256sum -c --
chmod +x ./mariadb_es_repo_setup
old_ver='10.5.8-5'
cur_ver='10.5'
repo_file='/etc/yum.repos.d/mariadb.repo'
sudo ./mariadb_es_repo_setup --token=${token} --apply --mariadb-server-version=${old_ver}
sudo dnf install MariaDB-server MariaDB-client
sudo sed -i "s/enterprise-server/enterprise-staging/" ${repo_file}
sudo sed -i "s/${old_ver}/${cur_ver}/" ${repo_file}
cat ${repo_file}
sudo dnf updateinfo list --security

The output from the `dnf updateinfo ...` command was:

[buildbot@rhel8-amd64 ~]$ sudo dnf updateinfo list --security
Updating Subscription Management repositories.
MariaDB Enterprise Server                                                             29 kB/s |  92 kB     00:03    
MariaDB MaxScale                                                                     2.1 kB/s | 2.4 kB     00:01    
MariaDB Tools                                                                         13 kB/s | 2.9 kB     00:00    
MariaDB-10.5.9_6 Unknown/Sec.   MariaDB-client-10.5.9_6-1.el8.x86_64
MariaDB-10.5.9_6 Unknown/Sec.   MariaDB-common-10.5.9_6-1.el8.x86_64
MariaDB-10.5.9_6 Unknown/Sec.   MariaDB-server-10.5.9_6-1.el8.x86_64
MariaDB-10.5.9_6 Unknown/Sec.   MariaDB-shared-10.5.9_6-1.el8.x86_64
MariaDB-10.5.9_6 Unknown/Sec.   galera-enterprise-4-26.4.7-1.el8.x86_64
RHSA-2021:0696   Moderate/Sec.  grub2-common-1:2.02-90.el8_3.1.noarch
RHSA-2021:0696   Moderate/Sec.  grub2-pc-1:2.02-90.el8_3.1.x86_64
RHSA-2021:0670   Important/Sec. bind-export-libs-32:9.11.20-5.el8_3.1.x86_64
RHSA-2021:0670   Important/Sec. bind-libs-32:9.11.20-5.el8_3.1.x86_64
...and etc...

Not sure why the MariaDB severity is listed as "Unknown". In my run of the gen-updateinfo.sh script I didn't change it from the script's default of "moderate". Does capitalization matter?

Comment by Daniel Bartholomew [ 2021-04-06 ]

On SLES 15 I ran the same tests, I just needed to modify the install steps to use zypper and change the repo_file to the correct location. Like so:

repo_file='/etc/zypp/repos.d/mariadb.repo' 
sudo zypper install MariaDB-server MariaDB-client
# run the sed lines to switch to staging and cur_version
sudo zypper clean
sudo zypper refresh
sudo zypper list-patches -a | grep -i mariadb

I ran into some install issues related to openssl, but that is probably because my SLES 15 test VM is running 15.0 instead of the latest version. So I just forced it to install MariaDB anyway. Also, when I updated the repositories I neglected to update the repomd.xml.asc signature file, so zypper complained about it (RHEL didn't seem to care for some reason).

The output of the `zypper list-patches ...` command was:

buildbot@sles150-amd64:~> sudo zypper list-patches -a | grep -i mariadb
MariaDB Enterprise Server                   | MariaDB-10.5.9_6                                    | security    | moderate  | ---         | needed     | MariaDB April/2021 update to 10.5.9_6-1
SLE-Module-Basesystem15-Updates             | SUSE-SLE-Module-Basesystem-15-2019-2020             | security    | important | ---         | not needed | Security update for mariadb, mariadb-connector-c
SLE-Module-Basesystem15-Updates             | SUSE-SLE-Module-Basesystem-15-2019-270              | recommended | important | ---         | not needed | Recommended update for mariadb-connector-c
...and etc...

Here the severity seems to be set properly. Also interesting that it lists SLES's own repo versions of MariaDB, but with a "not needed" tag.

Comment by Alexey Bychko (Inactive) [ 2021-04-06 ]

dbart perhaps capitalization does matter for RedHat. you may use --severity Moderate additional option when you're creating the updateinfo for RHEL.

from EPEL updateinfo file I see

<severity>Low</severity>

perhaps yes, RHEL has coded it in different way

Comment by Daniel Bartholomew [ 2021-04-06 ]

Specifying "Moderate" instead of "moderate" does indeed work for RHEL 8:

[buildbot@rhel8-amd64 ~]$ sudo dnf updateinfo list --security
Updating Subscription Management repositories.
MariaDB Enterprise Server                                                             29 kB/s |  92 kB     00:03    
MariaDB-10.5.9_6 Moderate/Sec.  MariaDB-client-10.5.9_6-1.el8.x86_64
MariaDB-10.5.9_6 Moderate/Sec.  MariaDB-common-10.5.9_6-1.el8.x86_64
MariaDB-10.5.9_6 Moderate/Sec.  MariaDB-server-10.5.9_6-1.el8.x86_64
MariaDB-10.5.9_6 Moderate/Sec.  MariaDB-shared-10.5.9_6-1.el8.x86_64

And SLES doesn't mind the capitalization, so we can stick with "Moderate" as our default, unless we're in a situation where we're making a special release for a critical update, in which case we can specify that instead.

So I will move forward with updating my automation to automatically add updateinfo.xml files to all our rpm repositories for future ES releases.

One final question: I'm guessing we want the same for CS releases?

Comment by Daniel Bartholomew [ 2021-04-06 ]

Additional test on CentOS 7 and it works just fine:

[buildbot@centos74-amd64 ~]$ sudo yum updateinfo list --security
Loaded plugins: fastestmirror
mariadb-es-main                                                                               | 3.3 kB  00:00:00     
mariadb-es-main/updateinfo                                                                    | 2.5 kB  00:00:00     
mariadb-es-main/primary_db                                                                    |  26 kB  00:00:00     
mariadb-maxscale                                                                              | 2.4 kB  00:00:00     
mariadb-tools                                                                                 | 2.9 kB  00:00:00     
Loading mirror speeds from cached hostfile
 * base: mirror.wwfx.net
 * epel: epel.uni-sofia.bg
 * extras: mirror.wwfx.net
 * updates: mirror.wwfx.net
MariaDB-10.5.9_6 Moderate/Sec. MariaDB-client-10.5.9_6-1.el7_9.x86_64
MariaDB-10.5.9_6 Moderate/Sec. MariaDB-common-10.5.9_6-1.el7_9.x86_64
MariaDB-10.5.9_6 Moderate/Sec. MariaDB-compat-10.5.9_6-1.el7_9.x86_64
MariaDB-10.5.9_6 Moderate/Sec. MariaDB-server-10.5.9_6-1.el7_9.x86_64
MariaDB-10.5.9_6 Moderate/Sec. galera-enterprise-4-26.4.7-1.el7_9.x86_64
updateinfo list done

Comment by Alexey Bychko (Inactive) [ 2021-04-07 ]

ok, changed the default to Moderate.
hholzgra do we need the same for CS and ES?

Comment by Alexey Bychko (Inactive) [ 2021-04-07 ]

one more detail: from support issue I see:

I would like to have the security fixes information delivered as part of the RPMs, so it can be listed with yum or dnf in the same way RHEL security issues can be checked

I'm wondering if it's just to list MariaDB in security updates OR it's about putting the details on security fix to xml. latter is more complicated and involving doc team.

example from RedHat:

<updates>
  <update status="final" from="release-engineering@redhat.com" version="1" type="security">
    <id>RHSA-2019:1142</id>
    <issued date="2019-05-13 04:48:13 UTC" />
    <title>Important: freeradius:3.0 security update</title>
    <release>0</release>
    <rights>Copyright 2019 Red Hat Inc</rights>
    <solution>For details on how to apply this update, which includes the changes described in this advisory, refer to:
 
https://access.redhat.com/articles/11258</solution>
    <severity>Important</severity>
    <summary>An update for the freeradius:3.0 module is now available for Red Hat Enterprise Linux 8.
 
Red Hat Product Security has rated this update as having a security impact of Important. A Common Vulnerability Scoring System (CVSS) base score, which gives a detailed severity rating, is available for each vulnerability from the CVE link(s) in the References section.</summary>
    <pushcount>2</pushcount>
    <description>FreeRADIUS is a high-performance and highly configurable free Remote Authentication Dial In User Service (RADIUS) server, designed to allow centralized authentication and authorization for a network.
 
Security Fix(es):
 
* freeradius: eap-pwd: authentication bypass via an invalid curve attack (CVE-2019-11235)
 
* freeradius: eap-pwd: fake authentication using reflection (CVE-2019-11234)
 
For more details about the security issue(s), including the impact, a CVSS score, acknowledgments, and other related information, refer to the CVE page(s) listed in the References section.</description>
    <updated date="2019-05-13 04:48:13 UTC" />
    <references>
      <reference href="https://access.redhat.com/errata/RHSA-2019:1142" type="self" id="RHSA-2019:1142" title="RHSA-2019:1142" />
      <reference href="https://bugzilla.redhat.com/show_bug.cgi?id=1695748" type="bugzilla" id="1695748" title="CVE-2019-11235 freeradius: eap-pwd: authentication bypass via an invalid curve attack" />
      <reference href="https://bugzilla.redhat.com/show_bug.cgi?id=1695783" type="bugzilla" id="1695783" title="CVE-2019-11234 freeradius: eap-pwd: fake authentication using reflection" />
      <reference href="https://www.redhat.com/security/data/cve/CVE-2019-11234.html" type="cve" id="CVE-2019-11234" title="CVE-2019-11234" />
      <reference href="https://www.redhat.com/security/data/cve/CVE-2019-11235.html" type="cve" id="CVE-2019-11235" title="CVE-2019-11235" />
      <reference href="https://access.redhat.com/security/updates/classification/#important" type="other" id="classification" title="important" />
    </references>
    <pkglist>
      <collection short="rhel-8-for-x86_64-appstream-rpms__8_DOT_0_1_freeradius">
        <name>rhel-8-for-x86_64-appstream-rpms__8_DOT_0_1_freeradius</name>
        <module stream="3.0" version="8000020190425181943" arch="x86_64" name="freeradius" context="75ec4169" />
        <package src="freeradius-3.0.17-4.module+el8.0.0+3108+851cb559.src.rpm" name="freeradius" epoch="0" version="3.0.17" release="4.module+el8.0.0+3108+851cb559" arch="x86_64">

Comment by Alexey Bychko (Inactive) [ 2021-04-07 ]

discussed the issue with serg, need to adjust the script to use it for both CS & ES. and maybe we need to move my script to mariadb.org-tools repository
dbart will do tomorrow ^^^

Comment by Alexey Bychko (Inactive) [ 2021-04-08 ]

updated according to serg's comments. dbart please re-test and put the script to mariadb.org-tools repository if it's OK

Comment by Daniel Bartholomew [ 2021-04-09 ]

Ran another test and things look OK.

Added the script to the mariadb.org-tools repository.

Comment by Daniel Bartholomew [ 2021-04-09 ]

I've also updated my prep scripts so that this new script is run automatically when I create the repositories (for both regular and Enterprise MariaDB releases)

Comment by Daniel Bartholomew [ 2021-04-12 ]

ralf.gebhardt@mariadb.com All I'm doing is running the gen-updateinfo.sh script for each rpm-based distribution and applying the generated updateinfo.xml file to the repo metadata:

https://github.com/MariaDB/mariadb.org-tools/blob/master/release/mkrepo-yum.sh#L722-L754

This happens during repository creation, so it will be there for every release.

As serg says, there won't be individual CVEs in the xml file. What is there is enough for the `yum updateinfo list --security` command to notify users that the new MariaDB release has security fixes and display a link to https://mariadb.com/kb/en/security/ where users can view the CVEs.

Comment by Sascha Glade [ 2021-05-08 ]

On Centos 7.9 I get the following error since yesterday:

Updateinfo file is not valid XML: <open file '/var/cache/yum/x86_64/7/mariadb/gen/updateinfo.xml', mode 'rt' at 0x7f7f463e46f0>

Upon checking the XML, line 3 isn't valid:

<update from="MariaDB Developers <maria-developers@mariadb.org>" status="stable" type="security" version="2.0">

The brackets around the e-mail address should be escaped with

&lt; 

and

&gt;

Comment by Vince Z [ 2021-05-08 ]

+1 for Sascha's comment.

$ sudo yum check-update
Loaded plugins: fastestmirror, langpacks
Loading mirror speeds from cached hostfile
...
Updateinfo file is not valid XML: <open file '/var/cache/yum/x86_64/7/mariadb10.3/gen/updateinfo.xml', mode 'rt' at 0x7fd70644aa50>

Centos 7.9 and started happening yesterday. I use:

$ cat /etc/yum.repos.d/mariadb10.3.repo
[mariadb10.3]
name=MariaDB.org 10.3
baseurl=http://yum.mariadb.org/10.3/centos$releasever-amd64
enabled=1
fastestmirror_enabled=0
gpgcheck=1
gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-MariaDB-10.3

Comment by Daniel Bartholomew [ 2021-05-08 ]

Working on fixing updateinfo.xml in the repositories...

Comment by Daniel Bartholomew [ 2021-05-08 ]

The 10.2.38, 10.3.29, 10.4.19, and 10.5.10 yum repositories have all been updated with fixed updateinfo.xml files.

Where they exist (not all of these exist for all MariaDB versions), the list of repositories updated includes:

  • fedora/32/aarch64
  • fedora/32/x86_64
  • fedora/33/aarch64
  • fedora/33/x86_64
  • opensuse/15/x86_64
  • rhel/7/aarch64
  • rhel/7/ppc64
  • rhel/7/ppc64le
  • rhel/7/x86_64
  • rhel/8/aarch64
  • rhel/8/ppc64le
  • rhel/8/x86_64
  • sles/12/x86_64
  • sles/15/x86_64

The repositories on yum.mariadb.org and downloads.mariadb.com are live with the fix now. If you're using a repository from a 3rd-party mirror then the fix will not show up until that mirror next pulls from the primary mirror.

Comment by Sascha Glade [ 2021-05-08 ]

Confirming the issue is solved for me with the fix.
Thanks for the quick response!

Comment by Vince Z [ 2021-05-09 ]

Same for me. Thank you

Generated at Thu Feb 08 09:16:17 UTC 2024 using Jira 8.20.16#820016-sha1:9d11dbea5f4be3d4cc21f03a88dd11d8c8687422.