9:35 p.m.
On Mon, Apr 10, 2023 at 2:35 PM Stephen Smoogen <ssmoogen(a)redhat.com> wrote:
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...
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 signature checks that fail here? My reading of the
dnf.conf man file seem to suggest it should, but when I put it in my
dnf.conf for my global config, it doesn't seem to work. For reference, the
manual entry I am refering to says:
The nocrypto option will also set the _RPMVSF_NOSIGNATURES and
_RPMVSF_NODIGESTS VS flags. The test option provides a transaction check
without performing the transaction. It includes downloading of packages,
gpg keys check (including permanent import of additional keys if
necessary), and rpm check to prevent file conflicts.
2) If the tsflags option would work (or is supposed to work), is that also
a repo-level option? Could I enable that only for the repo that has the
problem here but keep the crypto checks for the other repos?
-Ian
--
Stephen Smoogen, Red Hat Automotive
Let us be kind to one another, for most of us are fighting a hard battle.
-- Ian MacClaren