Re: F38 DNF/RPM install errors due to header signatures

[Stephen Smoogen <ssmoogen@xxxxxxxxxx>]

On Mon, 10 Apr 2023 at 08:24, Ian McInerney via devel <devel@xxxxxxxxxxxxxxxxxxxxxxx> wrote:

On Mon, Apr 10, 2023 at 12:39 PM Stephen Smoogen <ssmoogen@xxxxxxxxxx> wrote:

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 :/

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