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

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

 



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@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?
> 
> 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)?

-- 
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab

Attachment: signature.asc
Description: PGP signature

--
_______________________________________________
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