Hello,
DNF5 got a complaint https://github.com/rpm-software-management/dnf5/issues/991 that "dnf update https://..." skips verifying package signatures:
$ sudo dnf update https://kojipkgs.fedoraproject.org//packages/gnome-control-center/45.1/2.fc4... https://kojipkgs.fedoraproject.org//packages/gnome-control-center/45.1/2.fc4... [...] Warning: skipped PGP checks for 2 package(s).
A DNF5 developer confirmed that old DNF4 does not verify signatures too. The verification happens only for packages comming from a repository. Why DNF5 looks bad is because it actually prints the warning and thus keeps the user better informed.
The nonchecking behavior probably exists to make installing local packages easy. If DNF5 would insist on checking the signatures, Fedora users would have to pass --no-gpgchecks option to their "dnf5" commands to override the new default, or start signing their packages. As always security is not easy.
Because this an old behavior and some users probably depend on it, enabling the verification for all cases looks like an abrupt change.
I would would like to hear your opinion: Should DNF5 start verifying all packages? Should DNF5 keep ignoring signatures for out-of-repository packages? Or should rather narrow the verification skip to packages from a local file system? Any other options?
-- Petr
On Tue, Oct 31, 2023 at 4:24 PM Petr Pisar ppisar@redhat.com wrote:
Hello,
DNF5 got a complaint https://github.com/rpm-software-management/dnf5/issues/991 that "dnf update https://..." skips verifying package signatures:
$ sudo dnf update https://kojipkgs.fedoraproject.org//packages/gnome-control-center/45.1/2.fc40/data/signed/a15b79cc/x86_64/gnome-control-center-45.1-2.fc40.x86_64.rpm https://kojipkgs.fedoraproject.org//packages/gnome-control-center/45.1/2.fc40/data/signed/a15b79cc/noarch/gnome-control-center-filesystem-45.1-2.fc40.noarch.rpm [...] Warning: skipped PGP checks for 2 package(s).
A DNF5 developer confirmed that old DNF4 does not verify signatures too. The verification happens only for packages comming from a repository. Why DNF5 looks bad is because it actually prints the warning and thus keeps the user better informed.
The nonchecking behavior probably exists to make installing local packages easy. If DNF5 would insist on checking the signatures, Fedora users would have to pass --no-gpgchecks option to their "dnf5" commands to override the new default, or start signing their packages. As always security is not easy.
Because this an old behavior and some users probably depend on it, enabling the verification for all cases looks like an abrupt change.
I would would like to hear your opinion: Should DNF5 start verifying all packages? Should DNF5 keep ignoring signatures for out-of-repository packages? Or should rather narrow the verification skip to packages from a local file system? Any other options?
I wonder - how would DNF (4 or 5 doesn't matter) know how to check that at all? I mean, if the package isn't associated with a repository (like installing an RPM directly), which GPG key should it even be checked against?
Fabio
V Tue, Oct 31, 2023 at 04:32:09PM +0100, Fabio Valentini napsal(a):
On Tue, Oct 31, 2023 at 4:24 PM Petr Pisar ppisar@redhat.com wrote:
Hello,
DNF5 got a complaint https://github.com/rpm-software-management/dnf5/issues/991 that "dnf update https://..." skips verifying package signatures:
$ sudo dnf update https://kojipkgs.fedoraproject.org//packages/gnome-control-center/45.1/2.fc40/data/signed/a15b79cc/x86_64/gnome-control-center-45.1-2.fc40.x86_64.rpm https://kojipkgs.fedoraproject.org//packages/gnome-control-center/45.1/2.fc40/data/signed/a15b79cc/noarch/gnome-control-center-filesystem-45.1-2.fc40.noarch.rpm [...] Warning: skipped PGP checks for 2 package(s).
A DNF5 developer confirmed that old DNF4 does not verify signatures too. The verification happens only for packages comming from a repository. Why DNF5 looks bad is because it actually prints the warning and thus keeps the user better informed.
The nonchecking behavior probably exists to make installing local packages easy. If DNF5 would insist on checking the signatures, Fedora users would have to pass --no-gpgchecks option to their "dnf5" commands to override the new default, or start signing their packages. As always security is not easy.
Because this an old behavior and some users probably depend on it, enabling the verification for all cases looks like an abrupt change.
I would would like to hear your opinion: Should DNF5 start verifying all packages? Should DNF5 keep ignoring signatures for out-of-repository packages? Or should rather narrow the verification skip to packages from a local file system? Any other options?
I wonder - how would DNF (4 or 5 doesn't matter) know how to check that at all? I mean, if the package isn't associated with a repository (like installing an RPM directly), which GPG key should it even be checked against?
Against any key already existing in an RPM database (rpm -qa | grep gpg-pubkey).
-- Petr
On Tue, Oct 31, 2023 at 11:57 AM Petr Pisar ppisar@redhat.com wrote:
V Tue, Oct 31, 2023 at 04:32:09PM +0100, Fabio Valentini napsal(a):
On Tue, Oct 31, 2023 at 4:24 PM Petr Pisar ppisar@redhat.com wrote:
Hello,
DNF5 got a complaint https://github.com/rpm-software-management/dnf5/issues/991 that "dnf update https://..." skips verifying package signatures:
$ sudo dnf update https://kojipkgs.fedoraproject.org//packages/gnome-control-center/45.1/2.fc40/data/signed/a15b79cc/x86_64/gnome-control-center-45.1-2.fc40.x86_64.rpm https://kojipkgs.fedoraproject.org//packages/gnome-control-center/45.1/2.fc40/data/signed/a15b79cc/noarch/gnome-control-center-filesystem-45.1-2.fc40.noarch.rpm [...] Warning: skipped PGP checks for 2 package(s).
A DNF5 developer confirmed that old DNF4 does not verify signatures too. The verification happens only for packages comming from a repository. Why DNF5 looks bad is because it actually prints the warning and thus keeps the user better informed.
The nonchecking behavior probably exists to make installing local packages easy. If DNF5 would insist on checking the signatures, Fedora users would have to pass --no-gpgchecks option to their "dnf5" commands to override the new default, or start signing their packages. As always security is not easy.
Because this an old behavior and some users probably depend on it, enabling the verification for all cases looks like an abrupt change.
I would would like to hear your opinion: Should DNF5 start verifying all packages? Should DNF5 keep ignoring signatures for out-of-repository packages? Or should rather narrow the verification skip to packages from a local file system? Any other options?
I wonder - how would DNF (4 or 5 doesn't matter) know how to check that at all? I mean, if the package isn't associated with a repository (like installing an RPM directly), which GPG key should it even be checked against?
Against any key already existing in an RPM database (rpm -qa | grep gpg-pubkey).
Does DNF use the repository to verify GPG sigs now? If so, that seems weird. I would assume they just check against the existing keys in the RPM database, like Petr said.
I'm actually a bit concerned about this thread, because I assumed DNF4 and DNF5 would check signatures by default today, and that it would only skip if `--nogpgcheck` was passed as an option. If it sometimes skips the GPG check without that flag, that seems like a serious security bug to me. I would expect the same level of signature verification for both `dnf install mypackage` and `wget mypackage.rpm && dnf localinstall mypackage.rpm`.
After all, there is no documented flag to force a GPG signature check, only the flag to omit the check (`--nogpgcheck`). So, users really have to rely on the default behavior of always checking GPG signatures if they want DNF to check them. If DNF is not doing that, that's really bad, because there's no way for users to force it to check them.
-- Petr
On Tue, 31 Oct 2023 12:48:31 -0400 Christopher ctubbsii@fedoraproject.org wrote:
I'm actually a bit concerned about this thread, because I assumed DNF4 and DNF5 would check signatures by default today, and that it would only skip if `--nogpgcheck` was passed as an option. If it sometimes skips the GPG check without that flag, that seems like a serious security bug to me. I would expect the same level of signature verification for both `dnf install mypackage` and `wget mypackage.rpm && dnf localinstall mypackage.rpm`.
After all, there is no documented flag to force a GPG signature check, only the flag to omit the check (`--nogpgcheck`). So, users really have to rely on the default behavior of always checking GPG signatures if they want DNF to check them. If DNF is not doing that, that's really bad, because there's no way for users to force it to check them.
Maybe not using dnf, but you can check it using rpm directly:
$ wget mypackage.rpm $ rpm --checksig mypackage.rpm
Regards, Paul.
On Wed, Nov 1, 2023 at 5:53 AM Paul Howarth paul@city-fan.org wrote:
On Tue, 31 Oct 2023 12:48:31 -0400 Christopher ctubbsii@fedoraproject.org wrote:
I'm actually a bit concerned about this thread, because I assumed DNF4 and DNF5 would check signatures by default today, and that it would only skip if `--nogpgcheck` was passed as an option. If it sometimes skips the GPG check without that flag, that seems like a serious security bug to me. I would expect the same level of signature verification for both `dnf install mypackage` and `wget mypackage.rpm && dnf localinstall mypackage.rpm`.
After all, there is no documented flag to force a GPG signature check, only the flag to omit the check (`--nogpgcheck`). So, users really have to rely on the default behavior of always checking GPG signatures if they want DNF to check them. If DNF is not doing that, that's really bad, because there's no way for users to force it to check them.
Maybe not using dnf, but you can check it using rpm directly:
$ wget mypackage.rpm $ rpm --checksig mypackage.rpm
Yeah, that's why DNF is more convenient for this... the whole point of using DNF to install a local file is for consistency of using the same command as for repo packages, not manually altering the RPM database outside of YUM/DNF (that results in a warning), and the expectation of it performing the standard checks. If it's not doing those checks, then I have to resort to doing that manually... but that undermines the whole convenience of DNF being capable of handling local RPMs for me. Why bother having that feature in DNF at all, if it doesn't add any value for local packages?
Regards, Paul. _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Christopher ctubbsii@fedoraproject.org writes:
$ wget mypackage.rpm $rpm --checksig mypackage.rpm
the whole point of using DNF to install a local file is for consistency of using the same command as for repo packages, not manually altering the RPM database outside of YUM/DNF (that results in a warning),
This isn't intended as a counter-argument, but I did want to point out that running rpm --checksig does not alter the RPM database; it just checks the signature. You would still install the package using DNF.
- J<
On 11/1/23 17:09, Christopher wrote:
On Wed, Nov 1, 2023 at 5:53 AM Paul Howarth paul@city-fan.org wrote:
Maybe not using dnf, but you can check it using rpm directly:
$ wget mypackage.rpm $ rpm --checksig mypackage.rpm
Yeah, that's why DNF is more convenient for this... the whole point of using DNF to install a local file is for consistency of using the same command as for repo packages, not manually altering the RPM database outside of YUM/DNF (that results in a warning), and the expectation of
FWIW, dnf doesn't issue any silly warnings about rpm changing its own database, that was a yum thing.
- Panu -
Dne 31. 10. 23 v 16:23 Petr Pisar napsal(a):
Hello,
DNF5 got a complaint https://github.com/rpm-software-management/dnf5/issues/991 that "dnf update https://..." skips verifying package signatures:
$ sudo dnf update https://kojipkgs.fedoraproject.org//packages/gnome-control-center/45.1/2.fc40/data/signed/a15b79cc/x86_64/gnome-control-center-45.1-2.fc40.x86_64.rpm https://kojipkgs.fedoraproject.org//packages/gnome-control-center/45.1/2.fc40/data/signed/a15b79cc/noarch/gnome-control-center-filesystem-45.1-2.fc40.noarch.rpm [...] Warning: skipped PGP checks for 2 package(s).
A DNF5 developer confirmed that old DNF4 does not verify signatures too. The verification happens only for packages comming from a repository. Why DNF5 looks bad is because it actually prints the warning and thus keeps the user better informed.
The nonchecking behavior probably exists to make installing local packages easy. If DNF5 would insist on checking the signatures, Fedora users would have to pass --no-gpgchecks option to their "dnf5" commands to override the new default, or start signing their packages. As always security is not easy.
Because this an old behavior and some users probably depend on it, enabling the verification for all cases looks like an abrupt change.
I would would like to hear your opinion: Should DNF5 start verifying all packages? Should DNF5 keep ignoring signatures for out-of-repository packages? Or should rather narrow the verification skip to packages from a local file system? Any other options?
Or maybe verify what it can and report the packages which can't be verified? You can notice that I was actually installing singed packages.
But I would (probably) not mind to explicitly specify `--no-gpgcheck`. I still would swear this used to be needed, that is why I try to install the signed packages.
Vít
On Tue, Oct 31, 2023 at 1:38 PM Vít Ondruch vondruch@redhat.com wrote:
Dne 31. 10. 23 v 16:23 Petr Pisar napsal(a):
Hello,
DNF5 got a complaint https://github.com/rpm-software-management/dnf5/issues/991 that "dnf update https://..." skips verifying package signatures:
$ sudo dnf update https://kojipkgs.fedoraproject.org//packages/gnome-control-center/45.1/2.fc40/data/signed/a15b79cc/x86_64/gnome-control-center-45.1-2.fc40.x86_64.rpm https://kojipkgs.fedoraproject.org//packages/gnome-control-center/45.1/2.fc40/data/signed/a15b79cc/noarch/gnome-control-center-filesystem-45.1-2.fc40.noarch.rpm [...] Warning: skipped PGP checks for 2 package(s).
A DNF5 developer confirmed that old DNF4 does not verify signatures too. The verification happens only for packages comming from a repository. Why DNF5 looks bad is because it actually prints the warning and thus keeps the user better informed.
The nonchecking behavior probably exists to make installing local packages easy. If DNF5 would insist on checking the signatures, Fedora users would have to pass --no-gpgchecks option to their "dnf5" commands to override the new default, or start signing their packages. As always security is not easy.
Because this an old behavior and some users probably depend on it, enabling the verification for all cases looks like an abrupt change.
I would would like to hear your opinion: Should DNF5 start verifying all packages? Should DNF5 keep ignoring signatures for out-of-repository packages? Or should rather narrow the verification skip to packages from a local file system? Any other options?
Or maybe verify what it can and report the packages which can't be verified? You can notice that I was actually installing singed packages.
But I would (probably) not mind to explicitly specify `--no-gpgcheck`. I still would swear this used to be needed, that is why I try to install the signed packages.
I could have sworn the same thing. I think that it should be an error if any package (it doesn't matter if it is local or not) cannot be verified, unless `--nogpgcheck` is specified. This seems like the only secure-by-default option. No RPM should be allowed to be installed if it can't be verified, unless the user explicitly allows it. If less secure options are provided (such as only providing a warning message or skipping verification of local RPMs), then an option must be provided to force the secure-behavior to prevent the installation of any RPMs that haven't been verified (something like `--requiregpgcheck`). But my strong preference is that it require GPG checks by default. That is the behavior that is implied by the existence of the `--nogpgcheck` flag and the non-existence of any other related flags.
Am Di., 31. Okt. 2023 um 19:31 Uhr schrieb Christopher < ctubbsii@fedoraproject.org>:
On Tue, Oct 31, 2023 at 1:38 PM Vít Ondruch vondruch@redhat.com wrote:
Dne 31. 10. 23 v 16:23 Petr Pisar napsal(a):
Hello,
DNF5 got a complaint https://github.com/rpm-software-management/dnf5/issues/991 that
"dnf update
https://..." skips verifying package signatures:
$ sudo dnf update
https://kojipkgs.fedoraproject.org//packages/gnome-control-center/45.1/2.fc4... https://kojipkgs.fedoraproject.org//packages/gnome-control-center/45.1/2.fc4...
[...] Warning: skipped PGP checks for 2 package(s).
A DNF5 developer confirmed that old DNF4 does not verify signatures
too.
The verification happens only for packages comming from a repository.
Why DNF5
looks bad is because it actually prints the warning and thus keeps the
user
better informed.
The nonchecking behavior probably exists to make installing local
packages
easy. If DNF5 would insist on checking the signatures, Fedora users
would have
to pass --no-gpgchecks option to their "dnf5" commands to override the
new
default, or start signing their packages. As always security is not
easy.
Because this an old behavior and some users probably depend on it,
enabling
the verification for all cases looks like an abrupt change.
I would would like to hear your opinion: Should DNF5 start verifying
all
packages? Should DNF5 keep ignoring signatures for out-of-repository
packages?
Or should rather narrow the verification skip to packages from a local
file
system? Any other options?
Or maybe verify what it can and report the packages which can't be verified? You can notice that I was actually installing singed packages.
But I would (probably) not mind to explicitly specify `--no-gpgcheck`. I still would swear this used to be needed, that is why I try to install the signed packages.
I could have sworn the same thing. I think that it should be an error if any package (it doesn't matter if it is local or not) cannot be verified, unless `--nogpgcheck` is specified. This seems like the only secure-by-default option. No RPM should be allowed to be installed if it can't be verified, unless the user explicitly allows it. If less secure options are provided (such as only providing a warning message or skipping verification of local RPMs), then an option must be provided to force the secure-behavior to prevent the installation of any RPMs that haven't been verified (something like `--requiregpgcheck`). But my strong preference is that it require GPG checks by default. That is the behavior that is implied by the existence of the `--nogpgcheck` flag and the non-existence of any other related flags.
Note that there are few differences between local and repo files here: - A repo comes with a key specification, i.e. an expected signer; a local package does not. What signature do you expect? What is the value of "any" signature? - A package installed via a repo comes "from the internet" without your control over the exact download location; a local package has been downloaded or built specifically by you, with you in control. Therefore, it does make sense that one has its signature checked and the other hasn't.
Michael
FWIW, from what I can recall, yum used to check all packages, but this resulted in tons of people complaining because they did not want it to check their local packages. So, a localpkg_gpgcheck option was added and set to false. dnf4 still has this option.
It's also worth noting that if you pass yum/dnf/dnf5 urls for the package(s) you want to install, it's not using a repo at all, it's downloading those packages and treating them as local packages.
kevin
On Tue, Oct 31, 2023 at 7:50 PM Kevin Fenzi kevin@scrye.com wrote:
FWIW, from what I can recall, yum used to check all packages, but this resulted in tons of people complaining because they did not want it to check their local packages. So, a localpkg_gpgcheck option was added and set to false. dnf4 still has this option.
I wasn't aware of that change in behavior. I can't find that option documented in the man page for dnf or any other readily available docs about dnf in my installation, or present in my dnf.conf file. I don't remember anybody ever complaining, certainly not "tons of people". Using local RPMs is a pretty rare thing. I can't imagine too many people complaining about this. It was never much of a burden, and to the extent that it was, it was a burden that was a worthwhile tradeoff for increased security.
It's also not clear when this option would take effect. Would it take effect if I did `dnf install /path/to/local/file` or just when I did `dnf localinstall /path/to/local/file`? What if I did `dnf localinstall remotepath:/to/remote/file`? All of these work, as it seems "localinstall" and "install" both just work if given a URL, local or remote.
This option seems poorly rolled out, unclear in function, and overall bad for security.
It's also worth noting that if you pass yum/dnf/dnf5 urls for the package(s) you want to install, it's not using a repo at all, it's downloading those packages and treating them as local packages.
Is this meant to imply that it doesn't do checks by default whenever you pass a URL?! That's even worse! From this user's perspective, a URL pointing to a package in a repo, is just a more fully-qualified way of specifying the shorthand package name. It seems very odd if passing a fully-qualified path to a remote package results in less security than specifying the (possibly ambiguous) shortname for a package that DNF resolves via NVR.
kevin _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
On Wed, Nov 01, 2023 at 11:05:33AM -0400, Christopher wrote:
On Tue, Oct 31, 2023 at 7:50 PM Kevin Fenzi kevin@scrye.com wrote:
FWIW, from what I can recall, yum used to check all packages, but this resulted in tons of people complaining because they did not want it to check their local packages. So, a localpkg_gpgcheck option was added and set to false. dnf4 still has this option.
I wasn't aware of that change in behavior. I can't find that option documented in the man page for dnf or any other readily available docs about dnf in my installation, or present in my dnf.conf file. I don't
Odd. It's in the dnf.conf man page here in rawhide:
"localpkg_gpgcheck boolean
Whether to perform a GPG signature check on local packages (packages in a file, not in a repository). The default is False. This option is subject to the active RPM security policy (see gpgcheck for more details). "
Looks like it was added to yum 13 years ago: https://github.com/rpm-software-management/yum/commit/290933489b1aaeb1017d10...
remember anybody ever complaining, certainly not "tons of people".
This was 13-14 years ago.
Using local RPMs is a pretty rare thing. I can't imagine too many people complaining about this. It was never much of a burden, and to the extent that it was, it was a burden that was a worthwhile tradeoff for increased security.
I'm just relaying the history here...
It's also not clear when this option would take effect. Would it take effect if I did `dnf install /path/to/local/file` or just when I did
no, because that looks up that file in your repos and downloads the repo version of the package.
`dnf localinstall /path/to/local/file`? What if I did `dnf
yes.
localinstall remotepath:/to/remote/file`? All of these work, as it seems "localinstall" and "install" both just work if given a URL, local or remote.
remote path just downloads the file and installs it, so it's the same as the last case.
This option seems poorly rolled out, unclear in function, and overall bad for security.
Well, nothing was rolled out, it's been that way for 13 years. Should it be revisited? Sure, and thats what this thread is for?
It's also worth noting that if you pass yum/dnf/dnf5 urls for the package(s) you want to install, it's not using a repo at all, it's downloading those packages and treating them as local packages.
Is this meant to imply that it doesn't do checks by default whenever you pass a URL?! That's even worse! From this user's perspective, a URL pointing to a package in a repo, is just a more fully-qualified way of specifying the shorthand package name. It seems very odd if
But dnf has no way to know https://foo.bar/packagename is in a repo. If it is, you should enable the repo and install it with 'dnf install packagename'.
passing a fully-qualified path to a remote package results in less security than specifying the (possibly ambiguous) shortname for a package that DNF resolves via NVR.
Yep.
kevin
On Wed, Nov 01, 2023 at 10:49:36AM -0700, Kevin Fenzi wrote:
On Wed, Nov 01, 2023 at 11:05:33AM -0400, Christopher wrote:
On Tue, Oct 31, 2023 at 7:50 PM Kevin Fenzi kevin@scrye.com wrote:
FWIW, from what I can recall, yum used to check all packages, but this resulted in tons of people complaining because they did not want it to check their local packages. So, a localpkg_gpgcheck option was added and set to false. dnf4 still has this option.
I wasn't aware of that change in behavior. I can't find that option documented in the man page for dnf or any other readily available docs about dnf in my installation, or present in my dnf.conf file. I don't
Odd. It's in the dnf.conf man page here in rawhide:
"localpkg_gpgcheck boolean
Whether to perform a GPG signature check on local packages (packages in a file, not in a repository). The default is False. This option is subject to the active RPM security policy (see gpgcheck for more details).
"
Looks like it was added to yum 13 years ago: https://github.com/rpm-software-management/yum/commit/290933489b1aaeb1017d10...
This is pretty badly documented. I'm pretty sure that most people will not guess that any URL qualifies as "in a file".
The approach to security nowadays is much stricter than 13 years ago… I think we should revisit this decision.
remember anybody ever complaining, certainly not "tons of people".
This was 13-14 years ago.
Using local RPMs is a pretty rare thing. I can't imagine too many people complaining about this. It was never much of a burden, and to the extent that it was, it was a burden that was a worthwhile tradeoff for increased security.
I'm just relaying the history here...
It's also not clear when this option would take effect. Would it take effect if I did `dnf install /path/to/local/file` or just when I did
no, because that looks up that file in your repos and downloads the repo version of the package.
`dnf localinstall /path/to/local/file`? What if I did `dnf
My vote would be: 'dnf install /path/to/file' default to warn-but-allow (*) 'dnf install https://some.url/' default to an enforcing check
For files outside of a repo, the current set of keys registered with rpm should be used. A valid-signature-with-unknown-key must be rejected when the check is enforcing.
If such fine-grained policy is not possible, then I think defaulting to requiring explicit --nogpgcheck would be better than status quo.
(*) I think that 99% of the time when you're doing a local install like that, the package was built by the user and it's convenient to skip the check.
Zbyszek
On Wed, Nov 1, 2023 at 5:39 PM Zbigniew Jędrzejewski-Szmek zbyszek@in.waw.pl wrote:
On Wed, Nov 01, 2023 at 10:49:36AM -0700, Kevin Fenzi wrote:
On Wed, Nov 01, 2023 at 11:05:33AM -0400, Christopher wrote:
On Tue, Oct 31, 2023 at 7:50 PM Kevin Fenzi kevin@scrye.com wrote:
FWIW, from what I can recall, yum used to check all packages, but this resulted in tons of people complaining because they did not want it to check their local packages. So, a localpkg_gpgcheck option was added and set to false. dnf4 still has this option.
I wasn't aware of that change in behavior. I can't find that option documented in the man page for dnf or any other readily available docs about dnf in my installation, or present in my dnf.conf file. I don't
Odd. It's in the dnf.conf man page here in rawhide:
"localpkg_gpgcheck boolean
Whether to perform a GPG signature check on local packages (packages in a file, not in a repository). The default is False. This option is subject to the active RPM security policy (see gpgcheck for more details).
"
Looks like it was added to yum 13 years ago: https://github.com/rpm-software-management/yum/commit/290933489b1aaeb1017d10...
This is pretty badly documented. I'm pretty sure that most people will not guess that any URL qualifies as "in a file".
The approach to security nowadays is much stricter than 13 years ago… I think we should revisit this decision.
remember anybody ever complaining, certainly not "tons of people".
This was 13-14 years ago.
Using local RPMs is a pretty rare thing. I can't imagine too many people complaining about this. It was never much of a burden, and to the extent that it was, it was a burden that was a worthwhile tradeoff for increased security.
I'm just relaying the history here...
It's also not clear when this option would take effect. Would it take effect if I did `dnf install /path/to/local/file` or just when I did
no, because that looks up that file in your repos and downloads the repo version of the package.
`dnf localinstall /path/to/local/file`? What if I did `dnf
My vote would be: 'dnf install /path/to/file' default to warn-but-allow (*)
I don't think any "warn-but-allow" option is sufficient. The warning comes too late if the transaction is allowed to proceed. By the time the user can react, the installation scripts could have already corrupted the system due to installing a malicious or corrupted package, and possibly in a way that prevents them from reacting at all to the warning.
'dnf install https://some.url/' default to an enforcing check
For files outside of a repo, the current set of keys registered with rpm should be used. A valid-signature-with-unknown-key must be rejected when the check is enforcing.
If such fine-grained policy is not possible, then I think defaulting to requiring explicit --nogpgcheck would be better than status quo.
(*) I think that 99% of the time when you're doing a local install like that, the package was built by the user and it's convenient to skip the check.
I don't know how common it is for people to create their own RPMs, but that's necessarily going to be some subset of all Fedora users. I suspect there are many more users who install RPMs downloaded directly from others where these checks matter more (GPU drivers, Steam repackaging from Valve's DEBs, Amazon WorkSpaces client repackage made from Amazon's DEB using alien, Google Chrome initial installation RPM that sets up the Google YUM repo, Adobe Acrobat RPM, etc.), and who never build their own RPMs.
However, even for those who build their own RPMs, skipping this check is only going to be convenient for those who don't sign their own RPMs... which is a good practice and very easy to do. After all, these signatures don't just protect by authenticating the source of the package, but they also verify the package integrity to protect against file corruption.
Whatever inconvenience there is for users who build their own RPMs to add an explicit --nogpgcheck to a command-line, I think that's negligible compared to the benefit to everybody to verify by default. Perhaps the minor inconvenience will encourage those holdouts to adopt a better security posture and start signing the RPMs they build themselves?
Zbyszek _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
On Thu, Nov 02, 2023 at 09:58:10AM -0400, Christopher wrote:
On Wed, Nov 1, 2023 at 5:39 PM Zbigniew Jędrzejewski-Szmek zbyszek@in.waw.pl wrote:
On Wed, Nov 01, 2023 at 10:49:36AM -0700, Kevin Fenzi wrote:
On Wed, Nov 01, 2023 at 11:05:33AM -0400, Christopher wrote:
On Tue, Oct 31, 2023 at 7:50 PM Kevin Fenzi kevin@scrye.com wrote:
FWIW, from what I can recall, yum used to check all packages, but this resulted in tons of people complaining because they did not want it to check their local packages. So, a localpkg_gpgcheck option was added and set to false. dnf4 still has this option.
I wasn't aware of that change in behavior. I can't find that option documented in the man page for dnf or any other readily available docs about dnf in my installation, or present in my dnf.conf file. I don't
Odd. It's in the dnf.conf man page here in rawhide:
"localpkg_gpgcheck boolean
Whether to perform a GPG signature check on local packages (packages in a file, not in a repository). The default is False. This option is subject to the active RPM security policy (see gpgcheck for more details).
"
Looks like it was added to yum 13 years ago: https://github.com/rpm-software-management/yum/commit/290933489b1aaeb1017d10...
This is pretty badly documented. I'm pretty sure that most people will not guess that any URL qualifies as "in a file".
The approach to security nowadays is much stricter than 13 years ago… I think we should revisit this decision.
remember anybody ever complaining, certainly not "tons of people".
This was 13-14 years ago.
Using local RPMs is a pretty rare thing. I can't imagine too many people complaining about this. It was never much of a burden, and to the extent that it was, it was a burden that was a worthwhile tradeoff for increased security.
I'm just relaying the history here...
It's also not clear when this option would take effect. Would it take effect if I did `dnf install /path/to/local/file` or just when I did
no, because that looks up that file in your repos and downloads the repo version of the package.
`dnf localinstall /path/to/local/file`? What if I did `dnf
My vote would be: 'dnf install /path/to/file' default to warn-but-allow (*)
I don't think any "warn-but-allow" option is sufficient. The warning comes too late if the transaction is allowed to proceed. By the time the user can react, the installation scripts could have already corrupted the system due to installing a malicious or corrupted package, and possibly in a way that prevents them from reacting at all to the warning.
'dnf install https://some.url/' default to an enforcing check
For files outside of a repo, the current set of keys registered with rpm should be used. A valid-signature-with-unknown-key must be rejected when the check is enforcing.
If such fine-grained policy is not possible, then I think defaulting to requiring explicit --nogpgcheck would be better than status quo.
(*) I think that 99% of the time when you're doing a local install like that, the package was built by the user and it's convenient to skip the check.
I don't know how common it is for people to create their own RPMs, but that's necessarily going to be some subset of all Fedora users. I suspect there are many more users who install RPMs downloaded directly from others where these checks matter more (GPU drivers, Steam repackaging from Valve's DEBs, Amazon WorkSpaces client repackage made from Amazon's DEB using alien, Google Chrome initial installation RPM that sets up the Google YUM repo, Adobe Acrobat RPM, etc.), and who never build their own RPMs.
However, even for those who build their own RPMs, skipping this check is only going to be convenient for those who don't sign their own RPMs... which is a good practice and very easy to do. After all, these signatures don't just protect by authenticating the source of the package, but they also verify the package integrity to protect against file corruption.
Whatever inconvenience there is for users who build their own RPMs to add an explicit --nogpgcheck to a command-line, I think that's negligible compared to the benefit to everybody to verify by default. Perhaps the minor inconvenience will encourage those holdouts to adopt a better security posture and start signing the RPMs they build themselves?
I'm convinced by those arguments.
Zbyszek
On Sun, Nov 05, 2023 at 12:04:09PM +0000, Zbigniew Jędrzejewski-Szmek wrote:
On Thu, Nov 02, 2023 at 09:58:10AM -0400, Christopher wrote:
On Wed, Nov 1, 2023 at 5:39 PM Zbigniew Jędrzejewski-Szmek zbyszek@in.waw.pl wrote:
On Wed, Nov 01, 2023 at 10:49:36AM -0700, Kevin Fenzi wrote:
On Wed, Nov 01, 2023 at 11:05:33AM -0400, Christopher wrote:
On Tue, Oct 31, 2023 at 7:50 PM Kevin Fenzi kevin@scrye.com wrote:
FWIW, from what I can recall, yum used to check all packages, but this resulted in tons of people complaining because they did not want it to check their local packages. So, a localpkg_gpgcheck option was added and set to false. dnf4 still has this option.
I wasn't aware of that change in behavior. I can't find that option documented in the man page for dnf or any other readily available docs about dnf in my installation, or present in my dnf.conf file. I don't
Odd. It's in the dnf.conf man page here in rawhide:
"localpkg_gpgcheck boolean
Whether to perform a GPG signature check on local packages (packages in a file, not in a repository). The default is False. This option is subject to the active RPM security policy (see gpgcheck for more details).
"
Looks like it was added to yum 13 years ago: https://github.com/rpm-software-management/yum/commit/290933489b1aaeb1017d10...
This is pretty badly documented. I'm pretty sure that most people will not guess that any URL qualifies as "in a file".
The approach to security nowadays is much stricter than 13 years ago… I think we should revisit this decision.
remember anybody ever complaining, certainly not "tons of people".
This was 13-14 years ago.
Using local RPMs is a pretty rare thing. I can't imagine too many people complaining about this. It was never much of a burden, and to the extent that it was, it was a burden that was a worthwhile tradeoff for increased security.
I'm just relaying the history here...
It's also not clear when this option would take effect. Would it take effect if I did `dnf install /path/to/local/file` or just when I did
no, because that looks up that file in your repos and downloads the repo version of the package.
`dnf localinstall /path/to/local/file`? What if I did `dnf
My vote would be: 'dnf install /path/to/file' default to warn-but-allow (*)
I don't think any "warn-but-allow" option is sufficient. The warning comes too late if the transaction is allowed to proceed. By the time the user can react, the installation scripts could have already corrupted the system due to installing a malicious or corrupted package, and possibly in a way that prevents them from reacting at all to the warning.
'dnf install https://some.url/' default to an enforcing check
For files outside of a repo, the current set of keys registered with rpm should be used. A valid-signature-with-unknown-key must be rejected when the check is enforcing.
If such fine-grained policy is not possible, then I think defaulting to requiring explicit --nogpgcheck would be better than status quo.
(*) I think that 99% of the time when you're doing a local install like that, the package was built by the user and it's convenient to skip the check.
I don't know how common it is for people to create their own RPMs, but that's necessarily going to be some subset of all Fedora users. I suspect there are many more users who install RPMs downloaded directly from others where these checks matter more (GPU drivers, Steam repackaging from Valve's DEBs, Amazon WorkSpaces client repackage made from Amazon's DEB using alien, Google Chrome initial installation RPM that sets up the Google YUM repo, Adobe Acrobat RPM, etc.), and who never build their own RPMs.
However, even for those who build their own RPMs, skipping this check is only going to be convenient for those who don't sign their own RPMs... which is a good practice and very easy to do. After all, these signatures don't just protect by authenticating the source of the package, but they also verify the package integrity to protect against file corruption.
Whatever inconvenience there is for users who build their own RPMs to add an explicit --nogpgcheck to a command-line, I think that's negligible compared to the benefit to everybody to verify by default. Perhaps the minor inconvenience will encourage those holdouts to adopt a better security posture and start signing the RPMs they build themselves?
I'm convinced by those arguments.
There is one pitfall of using --nogpgcheck to install local unsigned RPM. If that RPM requires some dependencies to be downloaded from a repository, those dependencies will have signature check skipped too, no?
While I agree the default should be to check all signatures, there should be an obvious way to skip it for just local packages. As evidenced in this thread, --setopt=localpkg_gpgcheck=0 is not easy to find, people will try --nogpgcheck and that is bad. Maybe the error message should suggest the other option if the package is a local file (not from repository, and not given via http(s):// url)?
On Wed, Nov 1, 2023 at 1:50 PM Kevin Fenzi kevin@scrye.com wrote:
On Wed, Nov 01, 2023 at 11:05:33AM -0400, Christopher wrote:
On Tue, Oct 31, 2023 at 7:50 PM Kevin Fenzi kevin@scrye.com wrote:
FWIW, from what I can recall, yum used to check all packages, but this resulted in tons of people complaining because they did not want it to check their local packages. So, a localpkg_gpgcheck option was added and set to false. dnf4 still has this option.
I wasn't aware of that change in behavior. I can't find that option documented in the man page for dnf or any other readily available docs about dnf in my installation, or present in my dnf.conf file. I don't
Odd. It's in the dnf.conf man page here in rawhide:
"localpkg_gpgcheck boolean
Whether to perform a GPG signature check on local packages (packages in a file, not in a repository). The default is False. This option is subject to the active RPM security policy (see gpgcheck for more details).
"
You're right. I didn't see it before. I guess I wasn't looking in the right place. After finding it, though, I will say, the options, localpkg_gpgcheck, repo_gpgcheck, and gpgcheck, are all still a bit confusing to me, as currently worded. In addition to revisiting the defaults, I think there's room for improvement in these docs to make them more approachable to end users of DNF.
Looks like it was added to yum 13 years ago: https://github.com/rpm-software-management/yum/commit/290933489b1aaeb1017d10...
remember anybody ever complaining, certainly not "tons of people".
This was 13-14 years ago.
Using local RPMs is a pretty rare thing. I can't imagine too many people complaining about this. It was never much of a burden, and to the extent that it was, it was a burden that was a worthwhile tradeoff for increased security.
I'm just relaying the history here...
Understood. Thanks.
It's also not clear when this option would take effect. Would it take effect if I did `dnf install /path/to/local/file` or just when I did
no, because that looks up that file in your repos and downloads the repo version of the package.
That's not what I've seen. I've used this to explicitly install the Google Chrome RPM before from a local path... before the Chrome repo was set up, and it did not re-download the RPM from any repo. `dnf install ./google-chrome-stable.rpm`. I remember this because it was surprising to me that I didn't need to specify 'localinstall', that regular 'install' just worked. Ever since, I've assumed that 'localinstall' was just an alias for 'install' and didn't behave any differently. Perhaps that assumption is wrong, but that appeared to be the behavior I observed at the time.
`dnf localinstall /path/to/local/file`? What if I did `dnf
yes.
localinstall remotepath:/to/remote/file`? All of these work, as it seems "localinstall" and "install" both just work if given a URL, local or remote.
remote path just downloads the file and installs it, so it's the same as the last case.
This option seems poorly rolled out, unclear in function, and overall bad for security.
Well, nothing was rolled out, it's been that way for 13 years.
The way I was using the term "poorly rolled out", I just mean that it seems the way it was implemented or deployed ("rolled out") was less than ideal, regardless of when that occurred. Sorry if this wasn't clear. It's possible we use these terms differently.
Should it be revisited? Sure, and thats what this thread is for?
+1, and for what it's worth, my intent isn't to complain about previous decisions, but to offer a critical perspective that can be used constructively to inform future changes.
It's also worth noting that if you pass yum/dnf/dnf5 urls for the package(s) you want to install, it's not using a repo at all, it's downloading those packages and treating them as local packages.
Is this meant to imply that it doesn't do checks by default whenever you pass a URL?! That's even worse! From this user's perspective, a URL pointing to a package in a repo, is just a more fully-qualified way of specifying the shorthand package name. It seems very odd if
But dnf has no way to know https://foo.bar/packagename is in a repo. If it is, you should enable the repo and install it with 'dnf install packagename'.
That's not clear, because some package managers actually do work this way, and use the package name to construct a URL from a configured repo base. Maven2 repository layouts, for example, work by taking an package artifact specification and using that to construct a fully-qualified URL for an artifact on a base URL, so the package artifact spec really is just shorthand for a fully-qualified URL in a repo. This is also the way a human finds a package manually from the repo mirrors... by navigating to the base URL for the repo, and navigating down into the repo directories until you've constructed a URL directly to an RPM. So, it's not unreasonable for users to think DNF works similarly, and one could be easily confused into thinking that "dnf configured for repo at X URL and asked to install package Y" is equivalent to "dnf asked to install package at URL Y from repo base URL X", with the shorter package name specification just being shorthand for the fully-qualified URL. From a user perspective, it certainly *seems* like DNF is just constructing a URL for the package from the base URL for the repo and the package name. So the fact that it does different checks when DNF does that step, and when the user does it and provides the URL directly to DNF, can be surprising.
This is especially confusing to packagers who do know that it's the RPMs that contain the signatures themselves, and the RPM database contains the keys to verify those signatures. We know that the source URL or the originating repo doesn't actually matter... because RPM tools can verify the self-contained signature regardless. So, it's surprising that DNF would treat the source/repo as if it mattered for this is a bit unexpected.
passing a fully-qualified path to a remote package results in less security than specifying the (possibly ambiguous) shortname for a package that DNF resolves via NVR.
Yep.
kevin _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
On 11/2/23 06:36, Christopher wrote:
On Wed, Nov 1, 2023 at 1:50 PM Kevin Fenzi kevin@scrye.com wrote:
On Wed, Nov 01, 2023 at 11:05:33AM -0400, Christopher wrote:
It's also not clear when this option would take effect. Would it take effect if I did `dnf install /path/to/local/file` or just when I did
no, because that looks up that file in your repos and downloads the repo version of the package.
That's not what I've seen. I've used this to explicitly install the Google Chrome RPM before from a local path... before the Chrome repo was set up, and it did not re-download the RPM from any repo. `dnf install ./google-chrome-stable.rpm`. I remember this because it was surprising to me that I didn't need to specify 'localinstall', that regular 'install' just worked. Ever since, I've assumed that 'localinstall' was just an alias for 'install' and didn't behave any differently. Perhaps that assumption is wrong, but that appeared to be the behavior I observed at the time.
This was ambiguous and I think you were both considering different meanings.
You can dnf install a local rpm file, but you can also give dnf a path to an actual file (e.g. /usr/bin/bash) that can be installed and dnf will find and install the package that contains it.
# dnf install /usr/bin/bash Package bash-5.2.15-3.fc38.x86_64 is already installed.
On Sun, Nov 5, 2023 at 3:54 PM Samuel Sieb samuel@sieb.net wrote:
On 11/2/23 06:36, Christopher wrote:
On Wed, Nov 1, 2023 at 1:50 PM Kevin Fenzi kevin@scrye.com wrote:
On Wed, Nov 01, 2023 at 11:05:33AM -0400, Christopher wrote:
It's also not clear when this option would take effect. Would it take effect if I did `dnf install /path/to/local/file` or just when I did
no, because that looks up that file in your repos and downloads the repo version of the package.
That's not what I've seen. I've used this to explicitly install the Google Chrome RPM before from a local path... before the Chrome repo was set up, and it did not re-download the RPM from any repo. `dnf install ./google-chrome-stable.rpm`. I remember this because it was surprising to me that I didn't need to specify 'localinstall', that regular 'install' just worked. Ever since, I've assumed that 'localinstall' was just an alias for 'install' and didn't behave any differently. Perhaps that assumption is wrong, but that appeared to be the behavior I observed at the time.
This was ambiguous and I think you were both considering different meanings.
You can dnf install a local rpm file, but you can also give dnf a path to an actual file (e.g. /usr/bin/bash) that can be installed and dnf will find and install the package that contains it.
# dnf install /usr/bin/bash Package bash-5.2.15-3.fc38.x86_64 is already installed.
I was definitely referring to /path/to/existing/local/package.rpm, but I now understand the other behavior for /path/to/missing/file/to/find/and/install.
Thank you for the clarification! That makes sense now.
V Tue, Oct 31, 2023 at 04:49:30PM -0700, Kevin Fenzi napsal(a):
FWIW, from what I can recall, yum used to check all packages, but this resulted in tons of people complaining because they did not want it to check their local packages. So, a localpkg_gpgcheck option was added and set to false. dnf4 still has this option.
Thanks for bringing this option I did not know about. DNF5 supports it and it also defaults to false.
-- Petr
I believe that one of the strong complains was related to not signed packages. The use case is that when I build RPMs locally and then I install them (see bellow).
dnf install *.rpm --setopt=localpkg_gpgcheck=true ... Package dnf-4.17.1-1.git.9598.552e61e.fc38.noarch.rpm is not signed Package dnf-automatic-4.17.1-1.git.9598.552e61e.fc38.noarch.rpm is not signed Package dnf-data-4.17.1-1.git.9598.552e61e.fc38.noarch.rpm is not signed Package python3-dnf-4.17.1-1.git.9598.552e61e.fc38.noarch.rpm is not signed Package yum-4.17.1-1.git.9598.552e61e.fc38.noarch.rpm is not signed Error: GPG check FAILED
Jaroslav
On Tue, Nov 14, 2023 at 8:03 AM Jaroslav Mracek jmracek@redhat.com wrote:
I believe that one of the strong complains was related to not signed packages. The use case is that when I build RPMs locally and then I install them (see bellow).
dnf install *.rpm --setopt=localpkg_gpgcheck=true ... Package dnf-4.17.1-1.git.9598.552e61e.fc38.noarch.rpm is not signed Package dnf-automatic-4.17.1-1.git.9598.552e61e.fc38.noarch.rpm is not signed Package dnf-data-4.17.1-1.git.9598.552e61e.fc38.noarch.rpm is not signed Package python3-dnf-4.17.1-1.git.9598.552e61e.fc38.noarch.rpm is not signed Package yum-4.17.1-1.git.9598.552e61e.fc38.noarch.rpm is not signed Error: GPG check FAILED
Jaroslav
I think for the sake of security, it'd be better if this were on by default, and you just had to specify the --nogpgcheck For convenience, the error message should probably say "Error: GPG check FAILED (try again with '--nogpgcheck' to ignore)" I don't think this use case is so important that everybody's security should be lowered to avoid the minor inconvenience of passing a simple flag.
V Tue, Nov 14, 2023 at 08:16:39AM -0500, Christopher napsal(a):
On Tue, Nov 14, 2023 at 8:03 AM Jaroslav Mracek jmracek@redhat.com wrote:
I believe that one of the strong complains was related to not signed packages. The use case is that when I build RPMs locally and then I install them (see bellow).
dnf install *.rpm --setopt=localpkg_gpgcheck=true ... Package dnf-4.17.1-1.git.9598.552e61e.fc38.noarch.rpm is not signed Package dnf-automatic-4.17.1-1.git.9598.552e61e.fc38.noarch.rpm is not signed Package dnf-data-4.17.1-1.git.9598.552e61e.fc38.noarch.rpm is not signed Package python3-dnf-4.17.1-1.git.9598.552e61e.fc38.noarch.rpm is not signed Package yum-4.17.1-1.git.9598.552e61e.fc38.noarch.rpm is not signed Error: GPG check FAILED
Jaroslav
I think for the sake of security, it'd be better if this were on by default, and you just had to specify the --nogpgcheck
Technical note: --nogpgcheck does not imply localpkg_gpgcheck=false. Both of them operate independently. That's another painful property of the current code and documentation.
-- Petr
On Tue, Nov 14, 2023 at 9:24 AM Petr Pisar ppisar@redhat.com wrote:
V Tue, Nov 14, 2023 at 08:16:39AM -0500, Christopher napsal(a):
On Tue, Nov 14, 2023 at 8:03 AM Jaroslav Mracek jmracek@redhat.com wrote:
I believe that one of the strong complains was related to not signed packages. The use case is that when I build RPMs locally and then I install them (see bellow).
dnf install *.rpm --setopt=localpkg_gpgcheck=true ... Package dnf-4.17.1-1.git.9598.552e61e.fc38.noarch.rpm is not signed Package dnf-automatic-4.17.1-1.git.9598.552e61e.fc38.noarch.rpm is not signed Package dnf-data-4.17.1-1.git.9598.552e61e.fc38.noarch.rpm is not signed Package python3-dnf-4.17.1-1.git.9598.552e61e.fc38.noarch.rpm is not signed Package yum-4.17.1-1.git.9598.552e61e.fc38.noarch.rpm is not signed Error: GPG check FAILED
Jaroslav
I think for the sake of security, it'd be better if this were on by default, and you just had to specify the --nogpgcheck
Technical note: --nogpgcheck does not imply localpkg_gpgcheck=false. Both of them operate independently. That's another painful property of the current code and documentation.
-- Petr
Why wouldn't this apply? Both the documentation for 'dnf' and 'dnf.conf' use similar terminology "gpgcheck", and the man page says "Skip checking GPG signatures on packages (if RPM policy allows)." If it doesn't apply, it seems like it definitely *should*, for intuitiveness-sake. At the very least, if it doesn't apply, then the documentation is seriously deficient.
V Tue, Nov 14, 2023 at 01:25:08PM -0500, Christopher napsal(a):
On Tue, Nov 14, 2023 at 9:24 AM Petr Pisar ppisar@redhat.com wrote:
V Tue, Nov 14, 2023 at 08:16:39AM -0500, Christopher napsal(a):
On Tue, Nov 14, 2023 at 8:03 AM Jaroslav Mracek jmracek@redhat.com wrote:
I believe that one of the strong complains was related to not signed packages. The use case is that when I build RPMs locally and then I install them (see bellow).
dnf install *.rpm --setopt=localpkg_gpgcheck=true ... Package dnf-4.17.1-1.git.9598.552e61e.fc38.noarch.rpm is not signed Package dnf-automatic-4.17.1-1.git.9598.552e61e.fc38.noarch.rpm is not signed Package dnf-data-4.17.1-1.git.9598.552e61e.fc38.noarch.rpm is not signed Package python3-dnf-4.17.1-1.git.9598.552e61e.fc38.noarch.rpm is not signed Package yum-4.17.1-1.git.9598.552e61e.fc38.noarch.rpm is not signed Error: GPG check FAILED
Jaroslav
I think for the sake of security, it'd be better if this were on by default, and you just had to specify the --nogpgcheck
Technical note: --nogpgcheck does not imply localpkg_gpgcheck=false. Both of them operate independently. That's another painful property of the current code and documentation.
-- Petr
Why wouldn't this apply? Both the documentation for 'dnf' and 'dnf.conf' use similar terminology "gpgcheck", and the man page says "Skip checking GPG signatures on packages (if RPM policy allows)."
dnf.conf(5) reads (shortened):
gpgcheck Whether to perform GPG signature check on packages found in this repository.
localpkg_gpgcheck Whether to perform a GPG signature check on local packages (packages in a file, not in a repository).
it doesn't apply, it seems like it definitely *should*, for intuitiveness-sake.
I agree it's not intuitive. That's why SuSE wants the meaning of "gpgcheck" option to be configurable https://github.com/rpm-software-management/dnf5/issues/727.
-- Petr
On Tue, Nov 14 2023 at 08:16:39 AM -0500, Christopher ctubbsii@fedoraproject.org wrote:
I think for the sake of security, it'd be better if this were on by default, and you just had to specify the --nogpgcheck For convenience, the error message should probably say "Error: GPG check FAILED (try again with '--nogpgcheck' to ignore)" I don't think this use case is so important that everybody's security should be lowered to avoid the minor inconvenience of passing a simple flag.
Thing is, when manually installing RPMs that don't come from a repository, 98% of the time they are not expected to be signed by a GPG key that you have installed, so the check is expected to fail. GPG check is just not the right thing to do in this case. If we enable GPG checking when not appropriate, ***we will train users to reflexively ignore GPG errors.***
(We have already trained users to approve importing new GPG keys as long as they claim to be from Fedora, since this is required every Fedora release. This is bad enough.)
GPG check makes sense when installing RPMs from a configured repository, not when manually installing RPMs from a filesystem path or URL.
Michael
On Tue, Nov 14, 2023 at 9:30 AM Michael Catanzaro mcatanzaro@redhat.com wrote:
On Tue, Nov 14 2023 at 08:16:39 AM -0500, Christopher ctubbsii@fedoraproject.org wrote:
I think for the sake of security, it'd be better if this were on by default, and you just had to specify the --nogpgcheck For convenience, the error message should probably say "Error: GPG check FAILED (try again with '--nogpgcheck' to ignore)" I don't think this use case is so important that everybody's security should be lowered to avoid the minor inconvenience of passing a simple flag.
Thing is, when manually installing RPMs that don't come from a repository, 98% of the time they are not expected to be signed by a GPG key that you have installed, so the check is expected to fail.
The failure indicates that the source and integrity of the RPM is uncertain. The fact that the user is expected to make a conscious decision to bypass it when they want to accept that risk, but to be stopped if they don't want to accept that risk, is the whole point. So, yes, the check is expected to fail under those circumstances.
As for how common those circumstances are, I just surveyed my Fedora systems, and 100% of the RPMs I've manually installed, including some pertaining to Slack, Docker, Chrome, Jenkins, and InfluxDB, as well as my own that I've built, all are signed. In my personal experience, it's rare to come across an unsigned RPM. You may have a different experience, but the frequency isn't the point... the point is to provide protection by default and user choice to override and accept the risks. Right now, we have acceptance of risk by default instead of protection.
GPG check is just not the right thing to do in this case.
I disagree. I think it *is* the right thing to do to check, and offer the option to skip the check. That gives users the choice to be insecure if they want, but leaves the default secure.
If we enable GPG checking when not appropriate,
I disagree that the failure implies that GPG checking isn't appropriate. I think the fact that an un-bypassed check failed, in response to an RPM from an unknown or untrusted source, is very appropriate. The only time it would not be appropriate, in my opinion, is if the user chose to bypass it.
***we will train users to reflexively ignore GPG errors.***
So, your position is: "don't train users to ignore GPG errors... we'll ignore them for you" ?!?!
First, I don't agree that this will happen. I think it's more likely that users who are lax with security will continue to be lax with security, and users who aren't will pay attention to the failures and use that as a signal to inform their acceptance of the risks. But second, even if you're right, the worst case scenario here is the scenario we already have as the default: the check being ignored by the user is nearly the same as the check not being performed at all, which is what's happening today. If you're concerned that GPG errors will be ignored, I don't understand why you're not concerned with the fact that the only reason why users aren't seeing those errors today is because GPG checks aren't running at all! All the same security risks are still there... including the risks for an invalid or fraudulent signature when it is present on a local RPM, in addition to the risks when the signature is missing... they're just being ignored by default. You're worried about a situation where a user *might* ignore security check errors... but I'm worried that they are auto-ignored by the system, before the user even has a chance to take them seriously.
(We have already trained users to approve importing new GPG keys as long as they claim to be from Fedora, since this is required every Fedora release. This is bad enough.)
I don't agree with that either. I verify the signatures of Fedora keys using https://fedoraproject.org/security and the keys of other repos I use, and other users who care about security can do the same. I think Fedora has done as good a job as one can expect, for the most part, in trying to provide good security to those who care. But, of course, users have to care first and do their part as well.
GPG check makes sense when installing RPMs from a configured repository, not when manually installing RPMs from a filesystem path or URL.
Again, I completely disagree. The check protects against corrupt and/or malicious software, and is one of the few steps the package management system has to proactively prevent harm to the user's system *before* the harm is done. Skipping these checks by default is bad for software supply chain security, regardless of whether the supply chain involves a repo or just an RPM. The signatures are in the RPM, and the keys in the RPM database. The fact that it came from a repo or not is completely irrelevant for good software supply chain security defaults.
Michael
Am 14.11.23 um 22:04 schrieb Christopher:
On Tue, Nov 14, 2023 at 9:30 AM Michael Catanzaro mcatanzaro@redhat.com wrote:
On Tue, Nov 14 2023 at 08:16:39 AM -0500, Christopher ctubbsii@fedoraproject.org wrote:
I think for the sake of security, it'd be better if this were on by default, and you just had to specify the --nogpgcheck For convenience, the error message should probably say "Error: GPG check FAILED (try again with '--nogpgcheck' to ignore)" I don't think this use case is so important that everybody's security should be lowered to avoid the minor inconvenience of passing a simple flag.
Thing is, when manually installing RPMs that don't come from a repository, 98% of the time they are not expected to be signed by a GPG key that you have installed, so the check is expected to fail.
The failure indicates that the source and integrity of the RPM is uncertain. The fact that the user is expected to make a conscious decision to bypass it when they want to accept that risk, but to be stopped if they don't want to accept that risk, is the whole point. So, yes, the check is expected to fail under those circumstances.
As for how common those circumstances are, I just surveyed my Fedora systems, and 100% of the RPMs I've manually installed, including some pertaining to Slack, Docker, Chrome, Jenkins, and InfluxDB, as well as my own that I've built, all are signed. In my personal experience, it's rare to come across an unsigned RPM. You may have a different experience, but the frequency isn't the point... the point is to provide protection by default and user choice to override and accept the risks. Right now, we have acceptance of risk by default instead of protection.
GPG check is just not the right thing to do in this case.
I disagree. I think it *is* the right thing to do to check, and offer the option to skip the check. That gives users the choice to be insecure if they want, but leaves the default secure.
If we enable GPG checking when not appropriate,
I disagree that the failure implies that GPG checking isn't appropriate. I think the fact that an un-bypassed check failed, in response to an RPM from an unknown or untrusted source, is very appropriate. The only time it would not be appropriate, in my opinion, is if the user chose to bypass it.
***we will train users to reflexively ignore GPG errors.***
So, your position is: "don't train users to ignore GPG errors... we'll ignore them for you" ?!?!
First, I don't agree that this will happen. I think it's more likely that users who are lax with security will continue to be lax with security, and users who aren't will pay attention to the failures and use that as a signal to inform their acceptance of the risks. But second, even if you're right, the worst case scenario here is the scenario we already have as the default: the check being ignored by the user is nearly the same as the check not being performed at all, which is what's happening today. If you're concerned that GPG errors will be ignored, I don't understand why you're not concerned with the fact that the only reason why users aren't seeing those errors today is because GPG checks aren't running at all! All the same security risks are still there... including the risks for an invalid or fraudulent signature when it is present on a local RPM, in addition to the risks when the signature is missing... they're just being ignored by default. You're worried about a situation where a user *might* ignore security check errors... but I'm worried that they are auto-ignored by the system, before the user even has a chance to take them seriously.
(We have already trained users to approve importing new GPG keys as long as they claim to be from Fedora, since this is required every Fedora release. This is bad enough.)
I don't agree with that either. I verify the signatures of Fedora keys using https://fedoraproject.org/security and the keys of other repos I use, and other users who care about security can do the same. I think Fedora has done as good a job as one can expect, for the most part, in trying to provide good security to those who care. But, of course, users have to care first and do their part as well.
GPG check makes sense when installing RPMs from a configured repository, not when manually installing RPMs from a filesystem path or URL.
Again, I completely disagree. The check protects against corrupt and/or malicious software, and is one of the few steps the package management system has to proactively prevent harm to the user's system *before* the harm is done. Skipping these checks by default is bad for software supply chain security, regardless of whether the supply chain involves a repo or just an RPM. The signatures are in the RPM, and the keys in the RPM database. The fact that it came from a repo or not is completely irrelevant for good software supply chain security defaults.
I completly agree with you. Just wanted to note (as mcatanzaro already pointed at). Even when all sec-checks are enabled, the local install will produce an error because of the missing key (when its not a package of a configured repo). The user have to get (and import) the signing key securely ...
A common source for such keys is
rpm -qi distribution-gpg-keys
that package includes also keys of applications (not only distribution ones). For copr repos install distribution-gpg-keys-copr.
-- Leon
On Tue, Nov 14, 2023 at 5:02 PM Leon Fauster via devel devel@lists.fedoraproject.org wrote:
Am 14.11.23 um 22:04 schrieb Christopher:
On Tue, Nov 14, 2023 at 9:30 AM Michael Catanzaro mcatanzaro@redhat.com wrote:
On Tue, Nov 14 2023 at 08:16:39 AM -0500, Christopher ctubbsii@fedoraproject.org wrote:
I think for the sake of security, it'd be better if this were on by default, and you just had to specify the --nogpgcheck For convenience, the error message should probably say "Error: GPG check FAILED (try again with '--nogpgcheck' to ignore)" I don't think this use case is so important that everybody's security should be lowered to avoid the minor inconvenience of passing a simple flag.
Thing is, when manually installing RPMs that don't come from a repository, 98% of the time they are not expected to be signed by a GPG key that you have installed, so the check is expected to fail.
The failure indicates that the source and integrity of the RPM is uncertain. The fact that the user is expected to make a conscious decision to bypass it when they want to accept that risk, but to be stopped if they don't want to accept that risk, is the whole point. So, yes, the check is expected to fail under those circumstances.
As for how common those circumstances are, I just surveyed my Fedora systems, and 100% of the RPMs I've manually installed, including some pertaining to Slack, Docker, Chrome, Jenkins, and InfluxDB, as well as my own that I've built, all are signed. In my personal experience, it's rare to come across an unsigned RPM. You may have a different experience, but the frequency isn't the point... the point is to provide protection by default and user choice to override and accept the risks. Right now, we have acceptance of risk by default instead of protection.
GPG check is just not the right thing to do in this case.
I disagree. I think it *is* the right thing to do to check, and offer the option to skip the check. That gives users the choice to be insecure if they want, but leaves the default secure.
If we enable GPG checking when not appropriate,
I disagree that the failure implies that GPG checking isn't appropriate. I think the fact that an un-bypassed check failed, in response to an RPM from an unknown or untrusted source, is very appropriate. The only time it would not be appropriate, in my opinion, is if the user chose to bypass it.
***we will train users to reflexively ignore GPG errors.***
So, your position is: "don't train users to ignore GPG errors... we'll ignore them for you" ?!?!
First, I don't agree that this will happen. I think it's more likely that users who are lax with security will continue to be lax with security, and users who aren't will pay attention to the failures and use that as a signal to inform their acceptance of the risks. But second, even if you're right, the worst case scenario here is the scenario we already have as the default: the check being ignored by the user is nearly the same as the check not being performed at all, which is what's happening today. If you're concerned that GPG errors will be ignored, I don't understand why you're not concerned with the fact that the only reason why users aren't seeing those errors today is because GPG checks aren't running at all! All the same security risks are still there... including the risks for an invalid or fraudulent signature when it is present on a local RPM, in addition to the risks when the signature is missing... they're just being ignored by default. You're worried about a situation where a user *might* ignore security check errors... but I'm worried that they are auto-ignored by the system, before the user even has a chance to take them seriously.
(We have already trained users to approve importing new GPG keys as long as they claim to be from Fedora, since this is required every Fedora release. This is bad enough.)
I don't agree with that either. I verify the signatures of Fedora keys using https://fedoraproject.org/security and the keys of other repos I use, and other users who care about security can do the same. I think Fedora has done as good a job as one can expect, for the most part, in trying to provide good security to those who care. But, of course, users have to care first and do their part as well.
GPG check makes sense when installing RPMs from a configured repository, not when manually installing RPMs from a filesystem path or URL.
Again, I completely disagree. The check protects against corrupt and/or malicious software, and is one of the few steps the package management system has to proactively prevent harm to the user's system *before* the harm is done. Skipping these checks by default is bad for software supply chain security, regardless of whether the supply chain involves a repo or just an RPM. The signatures are in the RPM, and the keys in the RPM database. The fact that it came from a repo or not is completely irrelevant for good software supply chain security defaults.
I completly agree with you. Just wanted to note (as mcatanzaro already pointed at). Even when all sec-checks are enabled, the local install will produce an error because of the missing key (when its not a package of a configured repo). The user have to get (and import) the signing key securely ...
A common source for such keys is
rpm -qi distribution-gpg-keys
that package includes also keys of applications (not only distribution ones). For copr repos install distribution-gpg-keys-copr.
It is very common for RPMs to be unsigned from various vendors, because common RPM repository hosting services do not support signed RPMs. Notably almost everything I ever get from a packagecloud.io repository only has metadata signing with unsigned packages. This is also how *all* Debian repositories work. It is very rare for Debian packages to have debsigs so that they can be independently verified.
Dne 20. 11. 23 v 16:40 Neal Gompa napsal(a):
On Tue, Nov 14, 2023 at 5:02 PM Leon Fauster via devel devel@lists.fedoraproject.org wrote:
Am 14.11.23 um 22:04 schrieb Christopher:
On Tue, Nov 14, 2023 at 9:30 AM Michael Catanzaro mcatanzaro@redhat.com wrote:
On Tue, Nov 14 2023 at 08:16:39 AM -0500, Christopher ctubbsii@fedoraproject.org wrote:
I think for the sake of security, it'd be better if this were on by default, and you just had to specify the --nogpgcheck For convenience, the error message should probably say "Error: GPG check FAILED (try again with '--nogpgcheck' to ignore)" I don't think this use case is so important that everybody's security should be lowered to avoid the minor inconvenience of passing a simple flag.
Thing is, when manually installing RPMs that don't come from a repository, 98% of the time they are not expected to be signed by a GPG key that you have installed, so the check is expected to fail.
The failure indicates that the source and integrity of the RPM is uncertain. The fact that the user is expected to make a conscious decision to bypass it when they want to accept that risk, but to be stopped if they don't want to accept that risk, is the whole point. So, yes, the check is expected to fail under those circumstances.
As for how common those circumstances are, I just surveyed my Fedora systems, and 100% of the RPMs I've manually installed, including some pertaining to Slack, Docker, Chrome, Jenkins, and InfluxDB, as well as my own that I've built, all are signed. In my personal experience, it's rare to come across an unsigned RPM. You may have a different experience, but the frequency isn't the point... the point is to provide protection by default and user choice to override and accept the risks. Right now, we have acceptance of risk by default instead of protection.
GPG check is just not the right thing to do in this case.
I disagree. I think it *is* the right thing to do to check, and offer the option to skip the check. That gives users the choice to be insecure if they want, but leaves the default secure.
If we enable GPG checking when not appropriate,
I disagree that the failure implies that GPG checking isn't appropriate. I think the fact that an un-bypassed check failed, in response to an RPM from an unknown or untrusted source, is very appropriate. The only time it would not be appropriate, in my opinion, is if the user chose to bypass it.
***we will train users to reflexively ignore GPG errors.***
So, your position is: "don't train users to ignore GPG errors... we'll ignore them for you" ?!?!
First, I don't agree that this will happen. I think it's more likely that users who are lax with security will continue to be lax with security, and users who aren't will pay attention to the failures and use that as a signal to inform their acceptance of the risks. But second, even if you're right, the worst case scenario here is the scenario we already have as the default: the check being ignored by the user is nearly the same as the check not being performed at all, which is what's happening today. If you're concerned that GPG errors will be ignored, I don't understand why you're not concerned with the fact that the only reason why users aren't seeing those errors today is because GPG checks aren't running at all! All the same security risks are still there... including the risks for an invalid or fraudulent signature when it is present on a local RPM, in addition to the risks when the signature is missing... they're just being ignored by default. You're worried about a situation where a user *might* ignore security check errors... but I'm worried that they are auto-ignored by the system, before the user even has a chance to take them seriously.
(We have already trained users to approve importing new GPG keys as long as they claim to be from Fedora, since this is required every Fedora release. This is bad enough.)
I don't agree with that either. I verify the signatures of Fedora keys using https://fedoraproject.org/security and the keys of other repos I use, and other users who care about security can do the same. I think Fedora has done as good a job as one can expect, for the most part, in trying to provide good security to those who care. But, of course, users have to care first and do their part as well.
GPG check makes sense when installing RPMs from a configured repository, not when manually installing RPMs from a filesystem path or URL.
Again, I completely disagree. The check protects against corrupt and/or malicious software, and is one of the few steps the package management system has to proactively prevent harm to the user's system *before* the harm is done. Skipping these checks by default is bad for software supply chain security, regardless of whether the supply chain involves a repo or just an RPM. The signatures are in the RPM, and the keys in the RPM database. The fact that it came from a repo or not is completely irrelevant for good software supply chain security defaults.
I completly agree with you. Just wanted to note (as mcatanzaro already pointed at). Even when all sec-checks are enabled, the local install will produce an error because of the missing key (when its not a package of a configured repo). The user have to get (and import) the signing key securely ...
A common source for such keys is
rpm -qi distribution-gpg-keys
that package includes also keys of applications (not only distribution ones). For copr repos install distribution-gpg-keys-copr.
It is very common for RPMs to be unsigned from various vendors, because common RPM repository hosting services do not support signed RPMs. Notably almost everything I ever get from a packagecloud.io repository only has metadata signing with unsigned packages. This is also how *all* Debian repositories work. It is very rare for Debian packages to have debsigs so that they can be independently verified.
Reading this discussion, I have opened this RFE [1] to have more granular version of --no-gpgchecks
Vít
[1] https://github.com/rpm-software-management/dnf5/issues/1027
* Michael Catanzaro:
On Tue, Nov 14 2023 at 08:16:39 AM -0500, Christopher ctubbsii@fedoraproject.org wrote:
I think for the sake of security, it'd be better if this were on by default, and you just had to specify the --nogpgcheck For convenience, the error message should probably say "Error: GPG check FAILED (try again with '--nogpgcheck' to ignore)" I don't think this use case is so important that everybody's security should be lowered to avoid the minor inconvenience of passing a simple flag.
Thing is, when manually installing RPMs that don't come from a repository, 98% of the time they are not expected to be signed by a GPG key that you have installed, so the check is expected to fail. GPG check is just not the right thing to do in this case. If we enable GPG checking when not appropriate, ***we will train users to reflexively ignore GPG errors.***
We already trained them to use -y, which can automatically enroll new keys. I'm not sure if a trust boundary is crossed in that case, but if there isn't, why is user confirmation even needed?
Thanks, Florian
Hello all,
On Tuesday, November 14, 2023 8:16:39 AM EST Christopher wrote:
On Tue, Nov 14, 2023 at 8:03 AM Jaroslav Mracek jmracek@redhat.com wrote:
I believe that one of the strong complains was related to not signed packages. The use case is that when I build RPMs locally and then I install them (see bellow).
dnf install *.rpm --setopt=localpkg_gpgcheck=true ... Package dnf-4.17.1-1.git.9598.552e61e.fc38.noarch.rpm is not signed Package dnf-automatic-4.17.1-1.git.9598.552e61e.fc38.noarch.rpm is not signed
Package dnf-data-4.17.1-1.git.9598.552e61e.fc38.noarch.rpm is
not signed Package python3-dnf-4.17.1-1.git.9598.552e61e.fc38.noarch.rpm is not signed Package yum-4.17.1-1.git.9598.552e61e.fc38.noarch.rpm is not signed Error: GPG check FAILED
I think for the sake of security, it'd be better if this were on by default, and you just had to specify the --nogpgcheck For convenience, the error message should probably say "Error: GPG check FAILED (try again with '--nogpgcheck' to ignore)" I don't think this use case is so important that everybody's security should be lowered to avoid the minor inconvenience of passing a simple flag.
It's not just for the sake of security, there are actual security requirements that are specified around this for all distributions - no matter what the package manager is.
https://commoncriteria.github.io/pp/operatingsystem/operatingsystem-release....
There are 2 requirements, one on the metadata that dnf uses to decide if an update is available. The metadata must be signed and tested. Pass or fail needs to have an audit event that describes what was being done, what failed and if any checks are being overridden/bypassed.
The second requirements is on the update installation. It also requires auditing that describes what was being done, if the update was successful, what about it failed, and if any checks were being bypassed.
librpm has a module that can be installed that provides some of this auditing. But if dnf does it's own checks on metadata or the rpm before it passes it on to librpm, then it has to do the auditing itself. I would recommend making it an optional module so that people not wanting auditing are not impacted by any slow down during upgrades.
But the fact that it requires auditing means there are actual security expectations that need to be factored in - such as secure by default. If the audit trail shows that the rpms are passing gpg check, but it's not being enforced, that will get the attention of the security team.
And while we are talking update security, minimum hash sizes since last year are SHA384 and signatures being RSA 3072 and higher (this includes secure boot). There is also an expectation of moving away from RSA to quantum resistant algorithms in the next couple years. (This also means secure boot, too.)
-Steve
I would like to highlight a cool feature of DNF5 - drop-in directory for configuration overrides, where distribution may modify configuration of DNF5. Why I am mentioning it, because it allows to make a decision by distribution and the behavior might be modify outside of DNF5 package. Therefore the configuration option `localpkg_gpgcheck` might be modified by a Fedora distribution.
Not saying I am going to request Fedora to benefit from this, but since you have mentioned such feature, it would be super useful, if you also linked to an appropriate documentation.
Vít
Dne 14. 11. 23 v 14:12 Jaroslav Mracek napsal(a):
I would like to highlight a cool feature of DNF5 - drop-in directory for configuration overrides, where distribution may modify configuration of DNF5. Why I am mentioning it, because it allows to make a decision by distribution and the behavior might be modify outside of DNF5 package. Therefore the configuration option `localpkg_gpgcheck` might be modified by a Fedora distribution. _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
On Tue, 31 Oct 2023 16:23:41 +0100 Petr Pisar ppisar@redhat.com wrote:
I would would like to hear your opinion: Should DNF5 start verifying all packages? Should DNF5 keep ignoring signatures for out-of-repository packages? Or should rather narrow the verification skip to packages from a local file system? Any other options?
I build a local kernel from the src.rpm, and install it with
dnf -C install [etc.]
I never see this warning (dnf4). Would I start seeing it with dnf5? It is easy enough to add the --no-gpgchecks option if it is required, and it seems like a good reminder that the package being installed might be a security risk. Though, in my specific case, that isn't true if the fedora src.rpm is valid. A pretty safe bet.
On Tue, Oct 31, 2023 at 04:23:41PM +0100, Petr Pisar wrote:
The nonchecking behavior probably exists to make installing local packages easy. If DNF5 would insist on checking the signatures, Fedora users would have to pass --no-gpgchecks option to their "dnf5" commands to override the new default, or start signing their packages. As always security is not easy.
Because this an old behavior and some users probably depend on it, enabling the verification for all cases looks like an abrupt change.
I would would like to hear your opinion: Should DNF5 start verifying all packages? Should DNF5 keep ignoring signatures for out-of-repository packages? Or should rather narrow the verification skip to packages from a local file system? Any other options?
dnf should verify all packages unless the user turns this off.
I may have known checks were skipped for local files at one point, but reading this today I was surprised by it. Especially in today's world where instruction tell you to download the rpm and install it manually I think it is important to default to being as safe as possible by default.
I think we should:
* Switch the default local gpg check to true - this removes surprise when you learn you've been installing unchecked software for ... years? If they want it, it can be set back to false by the user.
* Don't apply the local flag to rpms downloaded from a url by dnf. Treat them as if they came from a repo. - users (or me) don't know all the internal paths inside dnf, the expectation is that a url isn't a local file.
Brian
On Thu, Nov 2, 2023 at 1:33 PM Brian C. Lane bcl@redhat.com wrote:
I think we should:
- Switch the default local gpg check to true
- this removes surprise when you learn you've been installing unchecked software for ... years? If they want it, it can be set back to false by the user.
- Don't apply the local flag to rpms downloaded from a url by dnf. Treat them as if they came from a repo.
- users (or me) don't know all the internal paths inside dnf, the expectation is that a url isn't a local file.
This seems like a reasonable default. Does it also make sense to add some CLI UI niceties that:
* Let's the user know this check may be skipped with "--nogpgcheck" with a brief explanation of the risk * Allow the user to continue the transaction with only the specific package not being checked, default no