On Sun, 9 Apr 2023 at 20:19, Ian McInerney via devel <devel@xxxxxxxxxxxxxxxxxxxxxxx> wrote:
On Mon, Apr 10, 2023 at 12:16 AM Samuel Sieb <samuel@xxxxxxxx> wrote:On 4/9/23 16:05, Ian McInerney via devel wrote:
> I decided to put F38 onto my new machine from the start (so a clean
> install), and now it seems to have some errors with DNF/RPM that I
> haven't seen before on F37 when I tried the same thing.
>
> Specifically, I am trying to install packages from a 3rd-party
> repository (the Intel oneAPI repo), and it is throwing errors like:
>
> package intel-basekit-2023.1.0-46401.x86_64 does not verify: RSA
> signature: BAD (package tag 1002: invalid OpenPGP signature)
> package intel-hpckit-2023.1.0-46346.x86_64 does not verify: RSA
> signature: BAD (package tag 1002: invalid OpenPGP signature)
>
> There are two things I don't understand here.
>
> The first is, why does DNF/RPM in F38 fail to parse this GPG signature,
> while DNF/RPM on F37 does parse it?
https://fedoraproject.org/wiki/Changes/RpmSequoia
See the upgrade impact and user experience sections.
You should contact Intel about fixing their packages.So we have pushed a change in Fedora where there is no nice way for a user to workaround it except by complaining to a company that probably doesn't care what normal users (e.g. non-paying customers) care about?
Basically the problem is that several checksums and types of keys are considered highly insecure and will cause problems for large numbers of users who have systems which need to meet general security rules in various industries. These include the SHA1 and DSA encryption keys and there are requirements that operating systems no longer ship these as enabled for the operating system to be used in universities, health care, etc. Where in the past these sorts of things have been 'given' a long time for removal (aka the 10+ years for MD5), my understanding is that these are being pushed much faster and harder than before. [Mainly in that continued funding from both public and private organizations is tied to audits etc.] The push is going to come in several 'waves' with SHA1 and DSA marked as bad now and in 1-2 years, SHA256 and RSA keys below 4096. Like most rapid changes, there is always going to be a lot of grit in the gears for everyone trying to continue working outside of the change :/
_______________________________________________After further experimentation, I finally did find a way to do what I want (install these packages) - disable all package verification via the RPM macro. I initially found the option `tsflags=nocrypto` for DNF, but after putting that in the config file, it still didn't work (the man page for dnf.conf seems to suggest this should disable the checks that were failing here, but it didn't disable those). Falling back all the way to RPM with the --nosignature argument isn't an option here, because installing ~60 RPM packages manually is not going to fly. I eventually forced DNF to make RPM do it by setting `%_pkgverify_level none` inside `macros.verify`. I really don't want to use this large a hammer to fix this though, and would much rather the nocrypto option actually worked with DNF, so I could then disable it just for the one repo.-Ian_______________________________________________
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
Stephen Smoogen, Red Hat Automotive
Let us be kind to one another, for most of us are fighting a hard battle. -- Ian MacClaren_______________________________________________ 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
