Re: DNF5: Checking signatures of packages installed out of a repository?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Wed, Nov 1, 2023 at 1:50 PM Kevin Fenzi <kevin@xxxxxxxxx> 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@xxxxxxxxx> 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@xxxxxxxxxxxxxxxxxxxxxxx
> To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
> 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@xxxxxxxxxxxxxxxxxxxxxxx
> Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
_______________________________________________
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
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@xxxxxxxxxxxxxxxxxxxxxxx
Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue




[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Users]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]

  Powered by Linux