Re: F38 DNF/RPM install errors due to header signatures
On Mon, Apr 10, 2023 at 2:35 PM Stephen Smoogen wrote: > > > On Mon, 10 Apr 2023 at 08:24, Ian McInerney via devel < > devel@lists.fedoraproject.org> wrote: > >> >> >> On Mon, Apr 10, 2023 at 12:39 PM Stephen Smoogen >> wrote: >> >>> >>> >>> On Sun, 9 Apr 2023 at 20:19, Ian McInerney via devel < >>> devel@lists.fedoraproject.org> wrote: >>> On Mon, Apr 10, 2023 at 12:16 AM Samuel Sieb 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 :/ >>> >>> >> This error has nothing to do with the crypto change that was made - I had >> already reverted that change and pushed my crypto settings back to >> DEFAULT:FEDORA32, and it still gave these errors. They are completely >> caused by an RPM change. >> >> > You are correct and I was wrong. I should have downloaded the RPM to see > what the problem was first. The problem looks to be related to > https://github.com/rpm-software-management/rpm/issues/2351 where certain > code use to create 'PGP' signatures actually does not conform to the > OpenPGP standard. > > > # rpm -vvvK intel-basekit-2023.1.0-2023.1.0-46401.x86_64.rpm > D: loading keyring from rpmdb > D: PRAGMA secure_delete = OFF: 0 > D: PRAGMA case_sensitive_like = ON: 0 > D: read h# 148 > Header SHA256 digest: OK > Header SHA1 digest: OK > D: added key gpg-pubkey-eb10b464-6202d9c6 to keyring > intel-basekit-2023.1.0-2023.1.0-46401.x86_64.rpm: > Header V4 RSA/SHA256 Signature, key ID 7e6c5dbe: NOKEY > Header SHA256 digest: OK > Header SHA1 digest: OK > Payload SHA256 digest: OK > RSA signature: BAD (package tag 1002: invalid OpenPGP signature) > MD5 digest: OK > > I can't see if the code was using the gocrypt code or something else but > it looks like > https://github.com/sylabs/golang-x-crypto/commit/374053ea96cb300f8671b8d3b07edeeb06e203b4#diff-47e53358306da9dcb5ca7dd110d31067d11f231fc3baed4f51e4026e26b521bfL506 > > > The crypto change was the first thing I blamed also (so I had downgraded my settings to Fedora 32, since I know it worked on Fedora 37 at least), since that was the most well advertised change due to all its discussion. The effect of switching the crypto RPM backend wasn't something that I would have thought would break things, and it certainly wasn't emphasized in the discussion like the breakage the crypto policy change would cause. The part of this change I am most annoyed at really is the lack of easy workarounds for working with affected packages - it makes for a bad UX. Two further points I would like clarification on: 1) Does the tsflags=nocrypto option in dnf.conf disable all crypto calls, including the package
Re: F38 DNF/RPM install errors due to header signatures
Stephen Smoogen wrote: > 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. And that is exactly what we are complaining about. It is not a reasonable thing to do to break algorithms that are still in widespread use. > [Mainly in that continued funding from both public and private > organizations is tied to audits etc.] Let the auditors complain all they want, they are not real-world users. The default configuration must work out of the box. Security extremists can always locally set some absurdly strict rules that will just not work but make clueless auditors happy. But they must not be the default. > 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 :/ That plan is absolutely unworkable and unacceptable. Kevin Kofler ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: F38 DNF/RPM install errors due to header signatures
On Monday, April 10, 2023 4:01:45 PM EDT Daniel Alley wrote: > >and in 1-2 years, SHA256 > > I've not seen any speculation much less evidence about sha256 being > insecure. Is this a post-quantum-crypto thing? Yes. There are a set of requirements called CNSA 1.0 that is being driven into all the security standards. They are selecting algorithms and key sizes that likely will stand up longer to efforts to crack them via quantum computers. Everything as of last fall needs to have at least 256 bit strength. So, sha384 is the current standard. RSA 3072 and greater are allowed as is ECDH P-512, and AES-256. Then in 2025, this all starts again with CNSA 2.0 where there's a transition period to quantum resistant algorithms. The target is everything transitioned by 2030. -Steve ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: F38 DNF/RPM install errors due to header signatures
>and in 1-2 years, SHA256 I've not seen any speculation much less evidence about sha256 being insecure. Is this a post-quantum-crypto thing? ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: F38 DNF/RPM install errors due to header signatures
On Mon, 10 Apr 2023 at 08:24, Ian McInerney via devel < devel@lists.fedoraproject.org> wrote: > > > On Mon, Apr 10, 2023 at 12:39 PM Stephen Smoogen > wrote: > >> >> >> On Sun, 9 Apr 2023 at 20:19, Ian McInerney via devel < >> devel@lists.fedoraproject.org> wrote: >> >>> >>> >>> On Mon, Apr 10, 2023 at 12:16 AM Samuel Sieb 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 :/ >> >> > This error has nothing to do with the crypto change that was made - I had > already reverted that change and pushed my crypto settings back to > DEFAULT:FEDORA32, and it still gave these errors. They are completely > caused by an RPM change. > > You are correct and I was wrong. I should have downloaded the RPM to see what the problem was first. The problem looks to be related to https://github.com/rpm-software-management/rpm/issues/2351 where certain code use to create 'PGP' signatures actually does not conform to the OpenPGP standard. # rpm -vvvK intel-basekit-2023.1.0-2023.1.0-46401.x86_64.rpm D: loading keyring from rpmdb D: PRAGMA secure_delete = OFF: 0 D: PRAGMA case_sensitive_like = ON: 0 D: read h# 148 Header SHA256 digest: OK Header SHA1 digest: OK D: added key gpg-pubkey-eb10b464-6202d9c6 to keyring intel-basekit-2023.1.0-2023.1.0-46401.x86_64.rpm: Header V4 RSA/SHA256 Signature, key ID 7e6c5dbe: NOKEY Header SHA256 digest: OK Header SHA1 digest: OK Payload SHA256 digest: OK RSA signature: BAD (package tag 1002: invalid OpenPGP signature) MD5 digest: OK I can't see if the code was using the gocrypt code or something else but it looks like https://github.com/sylabs/golang-x-crypto/commit/374053ea96cb300f8671b8d3b07edeeb06e203b4#diff-47e53358306da9dcb5ca7dd110d31067d11f231fc3baed4f51e4026e26b521bfL506 -- 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@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: F38 DNF/RPM install errors due to header signatures
Once upon a time, Stephen Smoogen said: > 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. I know RSA under 4096 is on the way out (despite the VAST majority of SSL certs using RSA 2048 keys), but I'm not aware of any push to deprecate SHA-256. Even the alternative to RSA certs, ECDSA, is still signed with SHA-256. -- Chris Adams ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: F38 DNF/RPM install errors due to header signatures
On Mon, Apr 10, 2023 at 12:39 PM Stephen Smoogen wrote: > > > On Sun, 9 Apr 2023 at 20:19, Ian McInerney via devel < > devel@lists.fedoraproject.org> wrote: > >> >> >> On Mon, Apr 10, 2023 at 12:16 AM Samuel Sieb 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 :/ > > This error has nothing to do with the crypto change that was made - I had already reverted that change and pushed my crypto settings back to DEFAULT:FEDORA32, and it still gave these errors. They are completely caused by an RPM change. Further searching turned up this RPM issue: https://github.com/rpm-software-management/rpm/issues/2351, which does have a similar error to the one I saw, pointing to the change to the sequoia backend being the root cause. The part I disagree with is that this is "expected behavior". How is it good UX to break a user's system with no way of overriding it? If there is that drastic a difference in behavior between the two backends, then there should be a way to recover the legacy behavior when needed. -Ian > > > >> >> 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@lists.fedoraproject.org >>> To unsubscribe send an email to devel-le...@lists.fedoraproject.org >>> 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@lists.fedoraproject.org >>> Do not reply to spam, report it: >>> https://pagure.io/fedora-infrastructure/new_issue >>> >> ___ >> devel mailing list -- devel@lists.fedoraproject.org >> To unsubscribe send an email to devel-le...@lists.fedoraproject.org >> Fedora Code of Conduct: >>
Re: F38 DNF/RPM install errors due to header signatures
On Sun, 9 Apr 2023 at 20:19, Ian McInerney via devel < devel@lists.fedoraproject.org> wrote: > > > On Mon, Apr 10, 2023 at 12:16 AM Samuel Sieb 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@lists.fedoraproject.org >> To unsubscribe send an email to devel-le...@lists.fedoraproject.org >> 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@lists.fedoraproject.org >> Do not reply to spam, report it: >> https://pagure.io/fedora-infrastructure/new_issue >> > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > 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@lists.fedoraproject.org > 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@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: F38 DNF/RPM install errors due to header signatures
> On Mon, Apr 10, 2023 at 12:16 AM Samuel Sieb > > 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? You can set LEGACY if you want to use packages with weak signatures. sudo update-crypto-policies --set LEGACY ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: F38 DNF/RPM install errors due to header signatures
On Mon, Apr 10, 2023 at 12:16 AM Samuel Sieb 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? 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@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > 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@lists.fedoraproject.org > Do not reply to spam, report it: > https://pagure.io/fedora-infrastructure/new_issue > ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: F38 DNF/RPM install errors due to header signatures
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. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
