On Wed, Nov 1, 2023 at 1:50 PM Kevin Fenzi <ke...@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 <ke...@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/290933489b1aaeb1017d10fb59ccf3231e309115 > > > 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-le...@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 _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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
