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:53 AM Paul Howarth <paul@xxxxxxxxxxxx> wrote:
>
> On Tue, 31 Oct 2023 12:48:31 -0400
> Christopher <ctubbsii@xxxxxxxxxxxxxxxxx> wrote:
> > I'm actually a bit concerned about this thread, because I assumed DNF4
> > and DNF5 would check signatures by default today, and that it would
> > only skip if `--nogpgcheck` was passed as an option. If it sometimes
> > skips the GPG check without that flag, that seems like a serious
> > security bug to me. I would expect the same level of signature
> > verification for both `dnf install mypackage` and `wget mypackage.rpm
> > && dnf localinstall mypackage.rpm`.
> >
> > After all, there is no documented flag to force a GPG signature check,
> > only the flag to omit the check (`--nogpgcheck`). So, users really
> > have to rely on the default behavior of always checking GPG signatures
> > if they want DNF to check them. If DNF is not doing that, that's
> > really bad, because there's no way for users to force it to check
> > them.
>
> Maybe not using dnf, but you can check it using rpm directly:
>
> $ wget mypackage.rpm
> $ rpm --checksig mypackage.rpm

Yeah, that's why DNF is more convenient for this... the whole point of
using DNF to install a local file is for consistency of using the same
command as for repo packages, not manually altering the RPM database
outside of YUM/DNF (that results in a warning), and the expectation of
it performing the standard checks. If it's not doing those checks,
then I have to resort to doing that manually... but that undermines
the whole convenience of DNF being capable of handling local RPMs for
me. Why bother having that feature in DNF at all, if it doesn't add
any value for local packages?

>
> Regards, Paul.
> _______________________________________________
> 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