Ensure DNF metadata is signed

[DemiMarie]

This helps mitigate DNF bugs.

[DemiMarie]

If Rocky winds up using the same signing infrastructure code that Fedora does, this could help get Fedora to sign their metadata, too.

[NeilHanlon]

Do you have any links to docs on this, for reference?

[DemiMarie]

https://github.com/QubesOS/qubes-linux-yum/commit/e981175aba8a27a088348e9a7bdf9a87c93c7529 implemented metadata signing in QubesOS. The metadata signature is just a standard detached GPG signature on the metadata XML.

[nazunalika]

dnf supports repos with gpg signed metadata with the .repo file having the option repo_gpgcheck=1. it is just a matter of actually signing the repo metadata using something like gpg --yes --detach-sign --armor repodata/repomd.xml which fedora and epel, do not do currently (why this is, I do not know, but there's nothing stopping them), and then having our own repo files have it set by default.

With that said, things like pulp (which satellite or upstream foreman use) support gpg_sign_metadata with patches or other manual work, which basically does this. And this will be something we will consider down the road when we get to a point when we're ready to start populating our repositories (considering we'll actually need to have our own scripted way of handling repos anyway after koji does its work).

Thank you for submitting this - We'll have this on our radar.

[NeilHanlon]

I'd imagine solving kms is what's stopping them... As is our challenge.

[DemiMarie]

I'd imagine solving kms is what's stopping them... As is our challenge.

Does “kms” mean “key management system”?

If so, my suggestion would be to sign the metadata the same way packages are signed. It is generated from signed inputs, after all.

[nazunalika]

What he's referring to is a key management system like HashiCorp Vault, like where the keys are going to be stored/pulled from on top of automation of such. Signing packages and repo metadata is a straight forward process using gpg. It's where and how the keys are managed and used is what he's referring to as being the challenge and is not fully within scope for this issue.

[DemiMarie]

Ah okay. What I meant is that signing packages and repo metadata can/should be done using the same system.

[cromerc]

To give some clarity, I know why a lot of distros don't sign their repos. First of all, if all packages in the repo are signed then signing the repo doesn't add any extra security. All that signing the meta data does is show that the meta data is correct, it doesn't effect whether or not the packages are correctly signed. Another issue is what happens when the repo is signed by a key that isn't in the user's keyring yet? They can't download the repo meta data because their keyring package has not been updated yet, and they can't update the keyring package because they can't download the repo meta data. The user ends up unable to update unless they disable signature checks.

The only time I usually see repos being signed in distros is when everything is either packaged by 1 person or by an automated system like jenkins. Then the 1 person or the system does all the signing instead of the maintainers. I don't usually see signed repos much on community based distros that have many maintainers.

[DemiMarie]

To give some clarity, I know why a lot of distros don't sign their repos. First of all, if all packages in the repo are signed then signing the repo doesn't add any extra security.

Yes and no. See the recent RPM vulnerabilities for cases where metadata signing would have helped. Also, signing the metadata helps prevent indefinite freeze attacks and inconsistent metadata.

All that signing the meta data does is show that the meta data is correct, it doesn't effect whether or not the packages are correctly signed. Another issue is what happens when the repo is signed by a key that isn't in the user's keyring yet? They can't download the repo meta data because their keyring package has not been updated yet, and they can't update the keyring package because they can't download the repo meta data. The user ends up unable to update unless they disable signature checks.

Keyring packages are rarely updated. Usually, they are only updated during a major distribution upgrade.

The only time I usually see repos being signed in distros is when everything is either packaged by 1 person or by an automated system like jenkins. Then the 1 person or the system does all the signing instead of the maintainers. I don't usually see signed repos much on community based distros that have many maintainers.

See Debian-based distros for a counterexample.

[nazunalika]

Until dnf repodata supports ValidUntil or a similar attribute and librepo no longer regards expired GPG signatures as fully valid, using repository gpg signing only goes half way. While repo signing does protect against modification of the repo data, it doesn't protect against attackers or outdated mirrors in any way. With that said, metalink would solve that in the interim until upstream has those issues resolved.

That's a main reason why a lot of distributions do not bother signing their repo metadata. Fedora is a good example of this.

[DemiMarie]

The main purpose of repo metadata signing is attack surface reduction. See:

• CVE-2020-14352
• CVE-2021-20721
• CVE-2021-3421

RCE possible in the first two cases.