search

rpm-software-management / rpm

The RPM package manager
http://rpm.org
Other
506 stars 366 forks source link

RFE: Enforce GPG signatures by default #1573

Open dmach opened 3 years ago

dmach commented 3 years ago

It might be good to start verifying GPG signatures by default. Adding --nogpcheck option (following what dnf has already) might be a good compromise for users that want to turn it off for individual package installs.

pmatilai commented 3 years ago

Rpm actually already verifies signatures if present by default since 4.0 or thereabouts, but it doesn't require them. Enforcing is supported since >= 4.14.2 and we also have the bypass-switch (--nosignature) already, so from strict technical perspective this is just a matter of one line change to turn the policy switch to 11 (%_pkgverify_level all).

The only thing stopping us is that it breaks the workflow of installing your own local builds - you need to sign or use --nosignature to install. For everything else this is 20 years too late already :sweat_smile: As the average user is not even affected at all... maybe the folks who build packages can be expected to deal with a little extra configuration to make the rest of the world that much safer.

DemiMarie commented 3 years ago

Rpm actually already verifies signatures if present by default since 4.0 or thereabouts, but it doesn't require them. Enforcing is supported since >= 4.14.2 and we also have the bypass-switch (--nosignature) already, so from strict technical perspective this is just a matter of one line change to turn the policy switch to 11 (%_pkgverify_level all).

The only thing stopping us is that it breaks the workflow of installing your own local builds - you need to sign or use --nosignature to install. For everything else this is 20 years too late already As the average user is not even affected at all... maybe the folks who build packages can be expected to deal with a little extra configuration to make the rest of the world that much safer.

Agreed. Those who build packages can generate their own signing keys. Personally, I would consider being able to disable this on a per-package basis a good idea, but it isn’t a blocker.

pmatilai commented 3 years ago

Personally, I would consider being able to disable this on a per-package basis a good idea, but it isn’t a blocker.

How is --nosignature failing to achieve that as it is?

DemiMarie commented 3 years ago

Personally, I would consider being able to disable this on a per-package basis a good idea, but it isn’t a blocker.

How is --nosignature failing to achieve that as it is?

It does for rpm(8), but not for dnf(8).

marmarek commented 3 years ago

A tricky case is when you mix local builds and downloaded packages in a single transaction. For example dnf install ./some-locally-built.rpm when that package requires some extra dependencies to be downloaded and installed. In my specific case, I have a local repository set (with baseurl=file:/// and gpgcheck=0) for packages I want to install from local build, and some (most) require extra dependencies to be downloaded from base (Fedora/CentOS) repositories. At DNF level this configuration is easy, because DNF knows where packages come from. But at RPM level they all looks the same, so requiring all the package be signed breaks this setup.

Signing local builds with some temporary key might workaround the problem, but I see few issues with that:

  1. It requires the key to be generated and appropriately protected. Normally I do keep important signing keys in HSM-like solution, which I don't really want to expose for some "temporary key". Not protecting such key may be fatal, as packages signed with it will be accepted by RPM/DNF, regardless of where they come from (this actually could be improved: to have DNF verify if packages are signed by the key configured for given repo, not just any key).
  2. If the build product includes an rpmdb, there is a risk of leaving this temporary key imported, giving it even more power. This for example affects container images. I guess this is rather rare case (to build a container from local "unsigned" packages), but such side effect may be surprising for some, and have fatal consequences.
  3. It may complicate stuff, if the packages are supposed to be signed later, or even some are already signed with a different key.

I don't have a good solution for this. This mostly seems like an issue of rpm not knowing a package origin. And letting it know that most likely will complicate interface significantly, which we definitely don't want in a security-critical code. Some solution could be giving rpm a list of package hashes to be excluded from the signature requirement. Then DNF could populate this list based on packages downloaded from gpgcheck=0 repositories. But I'm not sure if that isn't too complex already.

But generally, I think benefits of %_pkgverify_level all by default outweigh the above issues. Having an elegant solution for them would be nice to have, but should not block the change.