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