On Mon, 10 Apr 2023 at 08:24, Ian McInerney via devel <
devel(a)lists.fedoraproject.org> wrote:
On Mon, Apr 10, 2023 at 12:39 PM Stephen Smoogen <ssmoogen(a)redhat.com>
wrote:
>
>
> On Sun, 9 Apr 2023 at 20:19, Ian McInerney via devel <
> devel(a)lists.fedoraproject.org> wrote:
>
>>
>>
>> On Mon, Apr 10, 2023 at 12:16 AM Samuel Sieb <samuel(a)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/374053ea96cb300f8671b8d3...
--
Stephen Smoogen, Red Hat Automotive
Let us be kind to one another, for most of us are fighting a hard battle.
-- Ian MacClaren