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
