F38 DNF/RPM install errors due to header signatures

[Ian McInerney]

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?

Second, as a workaround I set both gpgcheck options in the repo file for
this repository to be 0, but it still returns the same errors, so why is it
still checking the GPG signature of the package if I disabled the GPG
checks for the entire repo?

For completeness, the versions are:

F38:
DNF 4.15.0-1.fc38
RPM 4.18.1-1.fc38

F37
DNF 4.14.0-1.fc37
RPM 4.18.0-1.fc37

Thanks,
-Ian

[Samuel Sieb]

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.

[Ian McInerney]

On Mon, Apr 10, 2023 at 12:16 AM Samuel Sieb <samuel(a)sieb.net&gt; 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(a)lists.fedoraproject.org
>  To unsubscribe send an email to devel-leave(a)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/[e-mail]
>  Do not reply to spam, report it:
>  https://pagure.io/fedora-infrastructure/new_issue
>

[Leigh Scott]

>  On Mon, Apr 10, 2023 at 12:16 AM Samuel Sieb
> <samuel(a)sieb.net&gt; wrote:
>  
>  
>  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

[Stephen Smoogen]

On Sun, 9 Apr 2023 at 20:19, Ian McInerney via devel <
devel(a)lists.fedoraproject.org&gt; wrote:

>  On Mon, Apr 10, 2023 at 12:16 AM Samuel Sieb <samuel(a)sieb.net&gt; 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(a)lists.fedoraproject.org
> > To unsubscribe send an email to devel-leave(a)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/[e-mail]
> > Do not reply to spam, report it:
> > https://pagure.io/fedora-infrastructure/new_issue
> >
>  _______________________________________________
>  devel mailing list -- devel(a)lists.fedoraproject.org
>  To unsubscribe send an email to devel-leave(a)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/[e-mail]
>  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

[Ian McInerney]

On Mon, Apr 10, 2023 at 12:39 PM Stephen Smoogen <ssmoogen(a)redhat.com&gt;
wrote:

>  On Sun, 9 Apr 2023 at 20:19, Ian McInerney via devel <
>  devel(a)lists.fedoraproject.org&gt; wrote:
>
> >
> >
> > On Mon, Apr 10, 2023 at 12:16 AM Samuel Sieb <samuel(a)sieb.net&gt; 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(a)lists.fedoraproject.org
> >> To unsubscribe send an email to devel-leave(a)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/[e-mail]
> >> Do not reply to spam, report it:
> >> https://pagure.io/fedora-infrastructure/new_issue
> >>
> > _______________________________________________
> > devel mailing list -- devel(a)lists.fedoraproject.org
> > To unsubscribe send an email to devel-leave(a)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/[e-mail]
> > 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(a)lists.fedoraproject.org
>  To unsubscribe send an email to devel-leave(a)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/[e-mail]
>  Do not reply to spam, report it:
>  https://pagure.io/fedora-infrastructure/new_issue
>

[Stephen Smoogen]

On Mon, 10 Apr 2023 at 08:24, Ian McInerney via devel <
devel(a)lists.fedoraproject.org&gt; wrote:

>  On Mon, Apr 10, 2023 at 12:39 PM Stephen Smoogen <ssmoogen(a)redhat.com&gt;
>  wrote:
>
> >
> >
> > On Sun, 9 Apr 2023 at 20:19, Ian McInerney via devel <
> > devel(a)lists.fedoraproject.org&gt; wrote:
> >
> >>
> >>
> >> On Mon, Apr 10, 2023 at 12:16 AM Samuel Sieb <samuel(a)sieb.net&gt; 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

[Ian McInerney]

On Mon, Apr 10, 2023 at 2:35 PM Stephen Smoogen <ssmoogen(a)redhat.com&gt; wrote:

>  On Mon, 10 Apr 2023 at 08:24, Ian McInerney via devel <
>  devel(a)lists.fedoraproject.org&gt; wrote:
>
> >
> >
> > On Mon, Apr 10, 2023 at 12:39 PM Stephen Smoogen <ssmoogen(a)redhat.com&gt;
> > wrote:
> >
> >>
> >>
> >> On Sun, 9 Apr 2023 at 20:19, Ian McInerney via devel <
> >> devel(a)lists.fedoraproject.org&gt; wrote:
> >>
> >>>
> >>>
> >>> On Mon, Apr 10, 2023 at 12:16 AM Samuel Sieb <samuel(a)sieb.net&gt; 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
>

[Chris Adams]

Once upon a time, Stephen Smoogen <ssmoogen(a)redhat.com&gt; 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 <linux(a)cmadams.net&gt;

[Daniel Alley]

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

[Steve Grubb]

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

[Kevin Kofler]

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