libdnf doesn't properly support multiple gpg public keys in repo config files, breaking microdnf

[jessecooper]

Version Info:

bash-4.2# rpm -aq | grep microdnf
microdnf-2-8.el7.x86_64

Taken from the yum man page:

Multiple URLs may be specified here in the same manner as the baseurl option (above). If a GPG key is required to install a package from a repository, all keys specified for that repository will be installed.

dnf/yum are able to accept multiple gpgkey keys like in the following example of mysql repo definition:

[mysql-connectors-community]
name=MySQL Connectors Community
baseurl=http://repo.mysql.com/yum/mysql-connectors-community/el/7/$basearch
enabled=1
gpgcheck=1
gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-mysql-2022
       file:///etc/pki/rpm-gpg/RPM-GPG-KEY-mysql

Microdnf will throw the following error until the secondary key is removed:

(microdnf:25): libdnf-WARNING **: 20:42:52.540: Skipping refresh of mysql80-community: Failed to download gpg key for repo 'mysql80-community': Curl error (37): Couldn't read a file:// file for file:///etc/pki/rpm-gpg/RPM-GPG-KEY-mysql-2022;file:///etc/pki/rpm-gpg/RPM-GPG-KEY-mysql [Couldn't open file /etc/pki/rpm-gpg/RPM-GPG-KEY-mysql-2022;file:///etc/pki/rpm-gpg/RPM-GPG-KEY-mysql]

[jrohel]

Microdnf supports multiple public gpg repo keys. The problem is in the multi-line notation in the configuration file.
Try to write all the keys on one line. Example:
gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-mysql-2022 file:///etc/pki/rpm-gpg/RPM-GPG-KEY-mysql

Dnf supports the non-standard multi-line extension of the INI format. Using single-line notation is a more compatible approach.
Multiple keys on a single line are supported in both dnf and microdnf.

[jessecooper]

@jrohel Thank you for the response it is good to understand there is a behavior difference between microdnf and dnf. I am sure this is going to trip people up and cause people to have to troubleshoot the issue as I did.

Would making it the same be too much overhead for microdnf?

[Conan-Kudo]

This is a libdnf bug rather than a microdnf bug, since the INI parsing is happening there.