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 <ssmoo...@redhat.com> > 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 <sam...@sieb.net> 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
