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 5:39 PM Zbigniew Jędrzejewski-Szmek
<zbyszek@xxxxxxxxx> 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@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).
> > "
> >
> > Looks like it was added to yum 13 years ago:
> > https://github.com/rpm-software-management/yum/commit/290933489b1aaeb1017d10fb59ccf3231e309115
>
> 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@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