Re: [Rpm-maint] [rpm-software-management/rpm] Enforce GPG signatures by default (#1573)
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. -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/1573#issuecomment-817363925___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Enforce GPG signatures by default (#1573)
> > 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)`. -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/1573#issuecomment-799505225___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Enforce GPG signatures by default (#1573)
> 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? -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/1573#issuecomment-799364236___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Enforce GPG signatures by default (#1573)
> 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. -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/1573#issuecomment-798172203___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Enforce GPG signatures by default (#1573)
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. -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/1573#issuecomment-793561939___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
