Re: F38 DNF/RPM install errors due to header signatures
On Mon, Apr 10, 2023 at 2:35 PM Stephen Smoogen wrote: > > > 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 >> 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 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 > > > 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
[EPEL-devel] Fedora EPEL 8 updates-testing report
The following Fedora EPEL 8 Security updates need testing: Age URL 25 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2023-1e00c3d01e cutter-re-2.2.0-1.el8 rizin-0.5.1-1.el8 6 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2023-d4a7c0e04e pdns-recursor-4.8.4-1.el8 6 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2023-9215c40764 zchunk-1.3.1-1.el8 4 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2023-b06600ebc7 bzip3-1.3.0-1.el8 The following builds have been pushed to Fedora EPEL 8 updates-testing icewm-3.3.3-2.el8 remmina-1.4.30-1.el8 Details about builds: icewm-3.3.3-2.el8 (FEDORA-EPEL-2023-f838d970bd) Window manager designed for speed, usability, and consistency Update Information: Update to latest version ChangeLog: * Mon Apr 10 2023 Artem Polishchuk - 3.3.3-1 - chore: Update to 3.3.3 remmina-1.4.30-1.el8 (FEDORA-EPEL-2023-deedf363e4) Remote Desktop Client Update Information: * Mon Apr 10 2023 Phil Wyett - 1.4.30-1 - New upstream version 1.4.30. - Use SPDX license identifiers. - Remove no longer needed patches. ChangeLog: * Mon Apr 10 2023 Phil Wyett - 1.4.30-1 - New upstream version 1.4.30. - Use SPDX license identifiers. - Remove no longer needed patches. ___ epel-devel mailing list -- epel-devel@lists.fedoraproject.org To unsubscribe send an email to epel-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/epel-devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
[Bug 1655461] w3c-markup-validator-23.4.10 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1655461 Upstream Release Monitoring changed: What|Removed |Added Summary|w3c-markup-validator-22.9.2 |w3c-markup-validator-23.4.1 |9 is available |0 is available --- Comment #37 from Upstream Release Monitoring --- Releases retrieved: 23.4.10.1, list, 21.3.3, 21.7.11, 21.7.12, 23.4.10 Upstream release that is considered latest: 23.4.10 Current version/release in rawhide: 1.3-26.fc38 URL: https://validator.github.io/validator/ Please consult the package updates policy before you issue an update to a stable branch: https://docs.fedoraproject.org/en-US/fesco/Updates_Policy/ More information about the service that created this bug can be found at: https://docs.fedoraproject.org/en-US/package-maintainers/Upstream_Release_Monitoring Please keep in mind that with any upstream change, there may also be packaging changes that need to be made. Specifically, please remember that it is your responsibility to review the new version to ensure that the licensing is still correct and that no non-free or legally problematic items have been added upstream. Based on the information from Anitya: https://release-monitoring.org/project/5111/ To change the monitoring settings for the project, please visit: https://src.fedoraproject.org/rpms/w3c-markup-validator -- You are receiving this mail because: You are on the CC list for the bug. https://bugzilla.redhat.com/show_bug.cgi?id=1655461 ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-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/perl-devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
[Bug 1655461] w3c-markup-validator-23.4.10 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1655461 --- Comment #38 from Upstream Release Monitoring --- Scratch build failed. Details below: BuilderException: Build failed: Command '['rpmbuild', '-D', '_sourcedir .', '-D', '_topdir .', '-bs', '/var/tmp/thn-bfzerr4u/w3c-markup-validator.spec']' returned non-zero exit status 1. StdOut: error: Bad source: ./w3c-markup-validator-23.4.10.tar.xz: No such file or directory Traceback: File "/usr/local/lib/python3.10/site-packages/hotness/use_cases/package_scratch_build_use_case.py", line 56, in build result = self.builder.build(request.package, request.opts) File "/usr/local/lib/python3.10/site-packages/hotness/builders/koji.py", line 188, in build raise BuilderException( If you think this issue is caused by some bug in the-new-hotness, please report it on the-new-hotness issue tracker: https://github.com/fedora-infra/the-new-hotness/issues -- You are receiving this mail because: You are on the CC list for the bug. https://bugzilla.redhat.com/show_bug.cgi?id=1655461 ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-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/perl-devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
[Bug 2177873] Please provide perl-Net-Amazon-S3 for EPEL9
https://bugzilla.redhat.com/show_bug.cgi?id=2177873 Bug 2177873 depends on bug 2178059, which changed state. Bug 2178059 Summary: Add perl-Data-Stream-Bulk to EPEL 9 https://bugzilla.redhat.com/show_bug.cgi?id=2178059 What|Removed |Added Status|ON_QA |CLOSED Resolution|--- |ERRATA -- You are receiving this mail because: You are on the CC list for the bug. https://bugzilla.redhat.com/show_bug.cgi?id=2177873 ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-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/perl-devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
[Bug 2178059] Add perl-Data-Stream-Bulk to EPEL 9
https://bugzilla.redhat.com/show_bug.cgi?id=2178059 Fedora Update System changed: What|Removed |Added Status|ON_QA |CLOSED Fixed In Version||perl-Data-Stream-Bulk-0.11- ||31.el9 Resolution|--- |ERRATA Last Closed||2023-04-11 00:50:26 --- Comment #3 from Fedora Update System --- FEDORA-EPEL-2023-cb60d23f23 has been pushed to the Fedora EPEL 9 stable repository. If problem still persists, please make note of it in this bug report. -- You are receiving this mail because: You are on the CC list for the bug. https://bugzilla.redhat.com/show_bug.cgi?id=2178059 ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-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/perl-devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
[EPEL-devel] Fedora EPEL 9 updates-testing report
The following Fedora EPEL 9 Security updates need testing: Age URL 6 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2023-911b83cb42 netatalk-3.1.14-3.el9 5 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2023-bb6f0bba09 pdns-recursor-4.8.4-1.el9 5 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2023-0ff8a4bc32 zchunk-1.3.1-1.el9 4 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2023-1fcf6a407e bzip3-1.3.0-1.el9 The following builds have been pushed to Fedora EPEL 9 updates-testing chromium-112.0.5615.49-1.el9 icewm-3.3.3-1.el9 remmina-1.4.30-1.el9 rust-io-lifetimes-1.0.10-1.el9 rust-is-terminal-0.4.7-1.el9 rust-libc-0.2.141-1.el9 rust-linux-raw-sys-0.3.1-1.el9 rust-rustix-0.37.11-2.el9 rust-tempfile-3.5.0-1.el9 rust-terminal_size-0.2.6-1.el9 vorta-0.8.12-2.el9 Details about builds: chromium-112.0.5615.49-1.el9 (FEDORA-EPEL-2023-7573786f98) A WebKit (Blink) powered web browser that Google doesn't want you to use Update Information: update to 112.0.5615.49. Fixes the following security issues: CVE-2023-1528 CVE-2023-1529 CVE-2023-1530 CVE-2023-1531 CVE-2023-1532 CVE-2023-1533 CVE-2023-1534, CVE-2023-25193 ChangeLog: * Wed Apr 5 2023 Than Ngo - 112.0.5615.49-1 - update to 112.0.5615.49 - fix #2184142, Small fonts in menus References: [ 1 ] Bug #2173489 - CVE-2023-25193 chromium: harfbuzz: allows attackers to trigger O(n^2) growth via consecutive marks [epel-8] https://bugzilla.redhat.com/show_bug.cgi?id=2173489 [ 2 ] Bug #2184142 - Small fonts in menus https://bugzilla.redhat.com/show_bug.cgi?id=2184142 [ 3 ] Bug #2184710 - CVE-2023-1810 CVE-2023-1811 CVE-2023-1812 CVE-2023-1813 CVE-2023-1814 CVE-2023-1815 CVE-2023-1816 CVE-2023-1817 CVE-2023-1818 CVE-2023-1819 CVE-2023-1820 CVE-2023-1821 CVE-2023-1822 CVE-2023-1823 chromium: various flaws [epel-all] https://bugzilla.redhat.com/show_bug.cgi?id=2184710 icewm-3.3.3-1.el9 (FEDORA-EPEL-2023-baaea66110) Window manager designed for speed, usability, and consistency Update Information: Update to latest version ChangeLog: * Mon Apr 10 2023 Artem Polishchuk - 3.3.3-1 - chore: Update to 3.3.3 remmina-1.4.30-1.el9 (FEDORA-EPEL-2023-cb05eaf8f2) Remote Desktop Client Update Information: * Mon Apr 10 2023 Phil Wyett - 1.4.30-1 - New upstream version 1.4.30. - Use SPDX license identifiers. - Remove no longer needed patches. ChangeLog: * Mon Apr 10 2023 Phil Wyett - 1.4.30-1 - New upstream version 1.4.30. - Use SPDX license identifiers. - Remove no longer needed patches. rust-io-lifetimes-1.0.10-1.el9 (FEDORA-EPEL-2023-cf9283e5fc) Low-level I/O ownership and borrowing library Update Information: - Update the rustix crate to version 0.37.11. - Update the io-lifetimes crate to version 1.0.10. - Update the is-terminal crate to version 0.4.7. - Update the libc crate to version 0.2.141. - Update the linux-raw-sys crate to version 0.3.1. - Update the tempfile crate to version 3.5.0. - Update the terminal_size crate to version 0.2.6. ChangeLog: * Mon Apr 10 2023 Fabio Valentini - 1.0.10-1 - Update to version 1.0.10; Fixes RHBZ#2184547 rust-is-terminal-0.4.7-1.el9 (FEDORA-EPEL-2023-cf9283e5fc) Test whether a given stream is a terminal Update Information: - Update the rustix crate to version 0.37.11. - Update the io-lifetimes crate to version 1.0.10. - Update the is-terminal crate to version 0.4.7. - Update the
[EPEL-devel] Fedora EPEL 7 updates-testing report
The following Fedora EPEL 7 Security updates need testing: Age URL 6 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2023-237e339dd2 netatalk-3.1.14-3.el7 5 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2023-d9256ecd7c zchunk-1.3.1-1.el7 The following builds have been pushed to Fedora EPEL 7 updates-testing chromium-112.0.5615.49-1.el7 Details about builds: chromium-112.0.5615.49-1.el7 (FEDORA-EPEL-2023-4821639cb4) A WebKit (Blink) powered web browser that Google doesn't want you to use Update Information: update to 112.0.5615.49. Fixes the following security issues: CVE-2023-1528 CVE-2023-1529 CVE-2023-1530 CVE-2023-1531 CVE-2023-1532 CVE-2023-1533 CVE-2023-1534, CVE-2023-25193 ChangeLog: * Wed Apr 5 2023 Than Ngo - 112.0.5615.49-1 - update to 112.0.5615.49 - fix #2184142, Small fonts in menus References: [ 1 ] Bug #2173489 - CVE-2023-25193 chromium: harfbuzz: allows attackers to trigger O(n^2) growth via consecutive marks [epel-8] https://bugzilla.redhat.com/show_bug.cgi?id=2173489 [ 2 ] Bug #2184142 - Small fonts in menus https://bugzilla.redhat.com/show_bug.cgi?id=2184142 [ 3 ] Bug #2184710 - CVE-2023-1810 CVE-2023-1811 CVE-2023-1812 CVE-2023-1813 CVE-2023-1814 CVE-2023-1815 CVE-2023-1816 CVE-2023-1817 CVE-2023-1818 CVE-2023-1819 CVE-2023-1820 CVE-2023-1821 CVE-2023-1822 CVE-2023-1823 chromium: various flaws [epel-all] https://bugzilla.redhat.com/show_bug.cgi?id=2184710 ___ epel-devel mailing list -- epel-devel@lists.fedoraproject.org To unsubscribe send an email to epel-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/epel-devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Schedule for Tuesday's FESCo Meeting (2023-04-11)
Following is the list of topics that will be discussed in the FESCo meeting Tuesday at 17:00UTC in #fedora-meeting on irc.libera.chat. To convert UTC to your local time, take a look at http://fedoraproject.org/wiki/UTCHowto or run: date -d '2023-04-11 17:00 UTC' Links to all issues to be discussed can be found at: https://pagure.io/fesco/report/meeting_agenda = Discussed and Voted in the Ticket = Change: EC2 AMIs default to the gp3 EBS volume type https://pagure.io/fesco/issue/2974 APPROVED (+5,0,-0) Change: Register EC2 Cloud Images with IMDSv2-only AMI flag https://pagure.io/fesco/issue/2975 APPROVED (+4,0,-0) Change: Changes of defaults in createrepo_c-1.0.0 https://pagure.io/fesco/issue/2976 APPROVED (+5,0,-0) = Followups = #2971 non-responsive maintainer policy doesn't say what happens when the maintainer repond https://pagure.io/fesco/issue/2971 #2979 RFC: Addressing package unretirement policy inconsistencies https://pagure.io/fesco/issue/2979 = New business = None = Open Floor = For more complete details, please visit each individual issue. The report of the agenda items can be found at https://pagure.io/fesco/report/meeting_agenda If you would like to add something to this agenda, you can reply to this e-mail, file a new issue at https://pagure.io/fesco, e-mail me directly, or bring it up at the end of the meeting, during the open floor topic. Note that added topics may be deferred until the following meeting. signature.asc Description: PGP signature ___ 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
Re: F38 DNF/RPM install errors due to header signatures
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 ___ 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
[Bug 2185669] New: perl-CPAN-Perl-Releases-5.20230410 is available
https://bugzilla.redhat.com/show_bug.cgi?id=2185669 Bug ID: 2185669 Summary: perl-CPAN-Perl-Releases-5.20230410 is available Product: Fedora Version: rawhide Status: NEW Component: perl-CPAN-Perl-Releases Keywords: FutureFeature, Triaged Assignee: jples...@redhat.com Reporter: upstream-release-monitor...@fedoraproject.org QA Contact: extras...@fedoraproject.org CC: iarn...@gmail.com, jples...@redhat.com, mspa...@redhat.com, perl-devel@lists.fedoraproject.org Target Milestone: --- Classification: Fedora Releases retrieved: 5.20230410 Upstream release that is considered latest: 5.20230410 Current version/release in rawhide: 5.20230320-1.fc39 URL: https://metacpan.org/dist/CPAN-Perl-Releases/ Please consult the package updates policy before you issue an update to a stable branch: https://docs.fedoraproject.org/en-US/fesco/Updates_Policy/ More information about the service that created this bug can be found at: https://docs.fedoraproject.org/en-US/package-maintainers/Upstream_Release_Monitoring Please keep in mind that with any upstream change, there may also be packaging changes that need to be made. Specifically, please remember that it is your responsibility to review the new version to ensure that the licensing is still correct and that no non-free or legally problematic items have been added upstream. Based on the information from Anitya: https://release-monitoring.org/project/5881/ To change the monitoring settings for the project, please visit: https://src.fedoraproject.org/rpms/perl-CPAN-Perl-Releases -- You are receiving this mail because: You are on the CC list for the bug. https://bugzilla.redhat.com/show_bug.cgi?id=2185669 ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-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/perl-devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Self Introduction: Miguel Bernal Marin
On 4/8/23 7:52 PM, Miguel Bernal Marin wrote: Hi Fedora community, My name is Miguel Bernal Marin and usually my nickname is miguelinux, I work at Intel corporation in Guadalajara, Jalisco, Mexico and I would like to add some new packages from Intel to Fedora and keep maintaining them. I will look for a sponsor for those package in a near future. Regarded my past experience on open source projects, I was in the Clear Linux team maintaining some packages, and I had contributed to others open source projects. My FAS user is miguelinux. Welcome Miguel. I am glad you have joined us! :) Joe -- Joe Doss j...@solidadmin.com ___ 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
Re: F38 DNF/RPM install errors due to header signatures
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 ___ 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
[rpms/perl-SNMP_Session] PR #1: Fix ipv6
spot merged a pull-request against the project: `perl-SNMP_Session` that you are following. Merged pull-request: `` Fix ipv6 `` https://src.fedoraproject.org/rpms/perl-SNMP_Session/pull-request/1 ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-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/perl-devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: F38 DNF/RPM install errors due to header signatures
>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? ___ 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
[EPEL-devel] Re: Intent to retire flintqs in EPEL7, EPEL8, and EPEL9 for security reasons
On Mon, Apr 10, 2023 at 10:40 AM Ben Beasley wrote: > When I took over maintenance of the flintqs package[1]—which contains > William Hart’s quadratic sieve implementation, as modified for > sagemath—I built it for EPEL7, EPEL8, and EPEL9. My thoughts were, “Why > not? Someone might find it useful.” > > It was recently pointed out[2][3] that the flintqs command-line tool > uses temporary files in unsafe ways[4], which could potentially > represent an exploitable security vulnerability; this has been assigned > CVE-2023-29465[5]. > > There is no immediate patch available; while one could surely be > constructed, the sagemath project plans to incorporate the factorization > algorithm directly in sagemath and discontinue support of the vulnerable > command-line tool rather than fixing it[6]. > > Since sagemath is not packaged in any of the EPEL releases, and flintqs > is therefore a leaf package, I plan to handle this security report by > retiring flintqs in all three EPELs. This email is the beginning of that > process as prescribed in the EPEL Retirement Policy: Process: Security > Reasons[7]. I doubt there will be any objections, but the process > requires a one-week discussion period, so I will follow up on the > epel-announce list and do the retirements no earlier than 2023-03-17. > > [1] https://src.fedoraproject.org/rpms/flintqs > > [2] https://bugzilla.redhat.com/show_bug.cgi?id=2185301 > > [3] https://github.com/sagemath/FlintQS/issues/3 > > [4] > https://owasp.org/www-community/vulnerabilities/Insecure_Temporary_File > > [5] https://nvd.nist.gov/vuln/detail/CVE-2023-29465 > > [6] https://github.com/sagemath/sage/pull/35419 > > [7] > > https://docs.fedoraproject.org/en-US/epel/epel-policy-retirement/#process_security_reasons > Thank you for following the retirement policy. I'm assuming that's a typo and you really meant "no earlier than 2023-04-17" Troy ___ epel-devel mailing list -- epel-devel@lists.fedoraproject.org To unsubscribe send an email to epel-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/epel-devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Orphaning pocl
On 10/04/2023 19:44, Tom Stellard wrote: I'm orphaning the pocl package. I'm not interested in maintaining it any more, and it's been FTBFS for the last 2 releases. I will take it and update to version 3.1 with LLVM 15+ support. -- Sincerely, Vitaly Zaitsev (vit...@easycoding.org) ___ 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
Fedora rawhide compose report: 20230410.n.0 changes
OLD: Fedora-Rawhide-20230409.n.0 NEW: Fedora-Rawhide-20230410.n.0 = SUMMARY = Added images:1 Dropped images: 1 Added packages: 2 Dropped packages:0 Upgraded packages: 62 Downgraded packages: 0 Size of added packages: 207.13 KiB Size of dropped packages:0 B Size of upgraded packages: 471.61 MiB Size of downgraded packages: 0 B Size change of upgraded packages: 3.05 MiB Size change of downgraded packages: 0 B = ADDED IMAGES = Image: Xfce raw-xz aarch64 Path: Spins/aarch64/images/Fedora-Xfce-Rawhide-20230410.n.0.aarch64.raw.xz = DROPPED IMAGES = Image: Kinoite dvd-ostree ppc64le Path: Kinoite/ppc64le/iso/Fedora-Kinoite-ostree-ppc64le-Rawhide-20230409.n.0.iso = ADDED PACKAGES = Package: rust-libadwaita-sys0.3-0.3.0-1.fc39 Summary: FFI bindings for libadwaita RPMs:rust-libadwaita-sys0.3+default-devel rust-libadwaita-sys0.3+dox-devel rust-libadwaita-sys0.3+v1_1-devel rust-libadwaita-sys0.3+v1_2-devel rust-libadwaita-sys0.3+v1_3-devel rust-libadwaita-sys0.3-devel Size:63.93 KiB Package: rust-libadwaita0.3-0.3.1-1.fc39 Summary: Rust bindings for libadwaita RPMs:rust-libadwaita0.3+default-devel rust-libadwaita0.3+dox-devel rust-libadwaita0.3+gtk_v4_2-devel rust-libadwaita0.3+gtk_v4_4-devel rust-libadwaita0.3+gtk_v4_6-devel rust-libadwaita0.3+v1_1-devel rust-libadwaita0.3+v1_2-devel rust-libadwaita0.3+v1_3-devel rust-libadwaita0.3-devel Size:143.20 KiB = DROPPED PACKAGES = = UPGRADED PACKAGES = Package: GeographicLib-2.2-3.fc39 Old package: GeographicLib-2.2-2.fc39 Summary: Library for geographic coordinate transformations RPMs: GeographicLib GeographicLib-devel GeographicLib-doc mingw32-GeographicLib mingw32-python3-GeographicLib mingw64-GeographicLib mingw64-python3-GeographicLib python3-GeographicLib Size: 3.95 MiB Size change: 1.67 KiB Changelog: * Sat Apr 08 2023 Orion Poplawski - 2.2-3 - Rebuild with octave 8.1.0 Package: NLopt-2.7.1-13.fc39 Old package: NLopt-2.7.1-12.fc38 Summary: Open-Source library for nonlinear optimization RPMs: NLopt NLopt-devel NLopt-doc guile-NLopt octave-NLopt python3-NLopt Size: 3.60 MiB Size change: -2.27 KiB Changelog: * Sat Apr 08 2023 Orion Poplawski - 2.7.1-13 - Rebuild with octave 8.1.0 Package: R-V8-4.3.0-1.fc39 Old package: R-V8-4.2.2-3.fc39 Summary: Embedded JavaScript and WebAssembly Engine for R RPMs: R-V8 Size: 1.60 MiB Size change: 12.10 KiB Changelog: * Sun Apr 09 2023 Elliott Sales de Andrade - 4.3.0-1 - Update to latest version (#2185377) Package: R-rJava-1.0.6-3.fc39 Old package: R-rJava-1.0.6-2.fc38 Summary: Low-Level R to Java Interface RPMs: R-rJava R-rJava-javadoc Size: 3.35 MiB Size change: -2.36 KiB Changelog: * Sun Apr 09 2023 Florian Weimer - 1.0.6-3 - Port configure script to C99 Package: apache-commons-exec-1.3-26.fc39 Old package: apache-commons-exec-1.3-24.fc37 Summary: Java library to reliably execute external processes from within the JVM RPMs: apache-commons-exec apache-commons-exec-javadoc Size: 219.78 KiB Size change: -30.50 KiB Changelog: * Wed Jan 18 2023 Fedora Release Engineering - 1.3-25 - Rebuilt for https://fedoraproject.org/wiki/Fedora_38_Mass_Rebuild * Sun Apr 09 2023 Mohamed El Morabity - 1.3-26 - Fix RHBZ #2171437 (FTBFS) Package: cawbird-1.4.2-6.fc39 Old package: cawbird-1.4.2-5.fc38 Summary: Fork of the Corebird GTK Twitter client that continues to work with Twitter RPMs: cawbird Size: 2.70 MiB Size change: 13.38 KiB Changelog: * Sun Apr 09 2023 Florian Weimer - 1.4.2-6 - Port to C99 (#2185474) Package: fish-3.6.1-1.fc39 Old package: fish-3.6.0-2.fc38 Summary: Friendly interactive shell RPMs: fish Size: 14.21 MiB Size change: 42.58 KiB Changelog: * Mon Apr 10 2023 Siteshwar Vashisht - 3.6.1-1 - Update to 3.6.1 Package: free42-1:3.0.19-1.fc39 Old package: free42-1:3.0.18-1.fc39 Summary: 42S Calculator Simulator RPMs: free42 Size: 7.38 MiB Size change: 825 B Changelog: * Mon Apr 10 2023 Yaakov Selkowitz - 1:3.0.19-1 - Update to 3.0.19 Package: freeipa-4.10.1-4.fc39 Old package: freeipa-4.10.1-3.fc38 Summary: The Identity, Policy and Audit system RPMs: freeipa-client freeipa-client-common freeipa-client-epn freeipa-client-samba freeipa-common freeipa-python-compat freeipa-selinux freeipa-server freeipa-server-common freeipa-server-dns freeipa-server-trust-ad python3-ipaclient python3-ipalib python3-ipaserver python3-ipatests Size: 9.58 MiB Size change: -20.84 KiB Changelog: * Thu Mar 30 2023 Jerry James - 4.10.1-4 - Change fontawesome-fonts R to match fontawesome 4.x Package: libfabric-1.18.0-1.fc39 Old package: libfabric-1.17.1-1.fc39 Summary: Open Fabric Interfaces RPMs
Orphaning pocl
Hi, I'm orphaning the pocl package. I'm not interested in maintaining it any more, and it's been FTBFS for the last 2 releases. -Tom ___ 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
[EPEL-devel] Intent to retire flintqs in EPEL7, EPEL8, and EPEL9 for security reasons
When I took over maintenance of the flintqs package[1]—which contains William Hart’s quadratic sieve implementation, as modified for sagemath—I built it for EPEL7, EPEL8, and EPEL9. My thoughts were, “Why not? Someone might find it useful.” It was recently pointed out[2][3] that the flintqs command-line tool uses temporary files in unsafe ways[4], which could potentially represent an exploitable security vulnerability; this has been assigned CVE-2023-29465[5]. There is no immediate patch available; while one could surely be constructed, the sagemath project plans to incorporate the factorization algorithm directly in sagemath and discontinue support of the vulnerable command-line tool rather than fixing it[6]. Since sagemath is not packaged in any of the EPEL releases, and flintqs is therefore a leaf package, I plan to handle this security report by retiring flintqs in all three EPELs. This email is the beginning of that process as prescribed in the EPEL Retirement Policy: Process: Security Reasons[7]. I doubt there will be any objections, but the process requires a one-week discussion period, so I will follow up on the epel-announce list and do the retirements no earlier than 2023-03-17. [1] https://src.fedoraproject.org/rpms/flintqs [2] https://bugzilla.redhat.com/show_bug.cgi?id=2185301 [3] https://github.com/sagemath/FlintQS/issues/3 [4] https://owasp.org/www-community/vulnerabilities/Insecure_Temporary_File [5] https://nvd.nist.gov/vuln/detail/CVE-2023-29465 [6] https://github.com/sagemath/sage/pull/35419 [7] https://docs.fedoraproject.org/en-US/epel/epel-policy-retirement/#process_security_reasons ___ epel-devel mailing list -- epel-devel@lists.fedoraproject.org To unsubscribe send an email to epel-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/epel-devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Future of encryption in Fedora
On Fri, Apr 7, 2023 at 5:12 AM Simo Sorce wrote: > On Thu, 2023-04-06 at 12:56 -0400, Owen Taylor wrote: > > On Thu, Apr 6, 2023 at 12:32 PM Simo Sorce wrote: > > > > > On Mon, 2023-04-03 at 16:18 -0500, Michael Catanzaro wrote: > > > > On Mon, Apr 3 2023 at 01:41:48 PM -0700, Brian C. Lane < > b...@redhat.com> > > > > wrote: > > > > > This seems like exactly the kind of discussion that belongs on the > > > > > devel > > > > > list, not on a website that I have to remember to visit for > updates. > > > > > > > > There is a notification bell in the right sidebar. Click it. ;) > > > > > > > > > > Or we can simply ignore that discussion until it lands in devel with a > > > change proposal. > > > > > > > Discussing on the forum was a suggestion from zbyszek and I think he > > proposed it in the same spirit that I agreed to the proposal - as an > > experiment in trying to align technical discussions more closely with the > > overall direction of the Fedora project for communication. > > > > I think we can see both pros and cons in how it's gone - on the good > side, > > people are involved that might not be involved otherwise, there's an > easily > > accessible public record of the conversation that is more readable than > > even a good mailing list archive, and having richer markup available is > > genuinely useful. > > > > On the downside, spam limits on new posters have gotten in the way in > some > > cases, and people have had some trouble figuring out how to use the > quoting > > features, resulting in disconnected responses. > > > > Yes, there will eventually be change proposals, which will be discussed > > here (unless anything changes...) but I would strongly encourage people > to > > get involved now in the discussion if they care about the topic - the > more > > we can get things right early, the better. > > Sorry Owen, > discourse is too disruptive for me to spend time on. > > I did try to skim the discussion and I think you have quite a few hints > already that this is not an easy path. > What I would recommend though, is to split this monster of a proposal > in smaller progressive steps. > There already *are* a lot of smaller progressive steps that are proposed for Fedora, or underway upstream, or already completed. But without at least a fuzzy big-picture story of where we're trying to get to, it's really hard to see how they relate to each other, or know what steps are missing. That's where I'm trying to get to. > You do not need to get everything super-tight-secure on the first try > (you won't be able to anyway), and building it in steps will allow you > to also (hopefully) offer a more fine-grained choice/configuration > later on. There's at least a need to know what the *recommended* combinations of options are, or it will be impossible to know whether super-tight-secure (or medium-tight-secure) has been achieved. - Owen ___ 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
[Bug 2185631] New: perl-Devel-CallChecker-0.009 is available
https://bugzilla.redhat.com/show_bug.cgi?id=2185631 Bug ID: 2185631 Summary: perl-Devel-CallChecker-0.009 is available Product: Fedora Version: rawhide Status: NEW Component: perl-Devel-CallChecker Keywords: FutureFeature, Triaged Assignee: mspa...@redhat.com Reporter: upstream-release-monitor...@fedoraproject.org QA Contact: extras...@fedoraproject.org CC: mspa...@redhat.com, p...@city-fan.org, perl-devel@lists.fedoraproject.org, ppi...@redhat.com Target Milestone: --- Classification: Fedora Releases retrieved: 0.009 Upstream release that is considered latest: 0.009 Current version/release in rawhide: 0.008-19.fc38 URL: http://search.cpan.org/dist/Devel-CallChecker/ Please consult the package updates policy before you issue an update to a stable branch: https://docs.fedoraproject.org/en-US/fesco/Updates_Policy/ More information about the service that created this bug can be found at: https://docs.fedoraproject.org/en-US/package-maintainers/Upstream_Release_Monitoring Please keep in mind that with any upstream change, there may also be packaging changes that need to be made. Specifically, please remember that it is your responsibility to review the new version to ensure that the licensing is still correct and that no non-free or legally problematic items have been added upstream. Based on the information from Anitya: https://release-monitoring.org/project/2822/ To change the monitoring settings for the project, please visit: https://src.fedoraproject.org/rpms/perl-Devel-CallChecker -- You are receiving this mail because: You are on the CC list for the bug. https://bugzilla.redhat.com/show_bug.cgi?id=2185631 ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-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/perl-devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: purpose of dummy-test-package-* updates?
On Mon, Apr 10, 2023 at 03:18:22PM +, Mattia Verga via devel wrote: > Il 10/04/23 17:01, Kevin Fenzi ha scritto: > > > > I've not seen any errors from it in a long while... but I'm not sure if > > thats because everything has been working or because it isn't erroring > > properly. > > > > Anyhow, I think we should/can adjust it to not make big changelogs... > > > Well, now the problem is no more, since Bodhi will handle such big > changelogs. > > Anyway, I'm not sure if it is working as expected, as updates are always > gated due to a failing test, so the next one will obsolete the older > (and that's why the changelog keeps growing). yeah, it deliberatly has a failed test so it can waive it and test that waiving works. Sadly, on looking, thats the problem. It tries to waive it but fails: 13:14:21 - Waiving test results for bodhi update Command `bodhi updates waive FEDORA-2023-47cf5a0c4b 'This is fine, we are testing the workflow ' --debug --user packagerbot --password ` return code: `1` stdout: --- b'Waiving unsatisfied requirements: \n' stderr: --- b'Invalid request: Check your FAS username & password\n' So, auth isn't working right there. kevin signature.asc Description: PGP signature ___ 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
Re: purpose of dummy-test-package-* updates?
Il 10/04/23 17:01, Kevin Fenzi ha scritto: > > I've not seen any errors from it in a long while... but I'm not sure if > thats because everything has been working or because it isn't erroring > properly. > > Anyhow, I think we should/can adjust it to not make big changelogs... > Well, now the problem is no more, since Bodhi will handle such big changelogs. Anyway, I'm not sure if it is working as expected, as updates are always gated due to a failing test, so the next one will obsolete the older (and that's why the changelog keeps growing). Mattia ___ 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
Re: purpose of dummy-test-package-* updates?
On Sun, Apr 09, 2023 at 06:35:44AM +, Mattia Verga via devel wrote: > Hello, > > I've recently introduced the cap of 10k characters in Bodhi updates > notes and made automatic updates avoid copying the RPM changelog in > notes if it's too big. This was causing some updates, especially those > created for `dummy-test-package-gloster` package [1], to clog Bodhi's > query replies. The way it does things may need adjusting... > > But what's the purpose of these "dummy" updates on production? Does > anyone knows it? In the past there were other "dummy" packages > (dummy-test-package-rubino and dummy-test-package-crested) which are no > more created, while -gloster is still pushed by an automated bot. I > wonder if someone forgot to disable that bot... This was setup when gating was added to rawhide. It's a small application that does a 'end to end' test of the build pipeline. ie, it does a real commit to git, a real build, watches for a real bodhi update, confirms that CI ran on it, checks greewave and waiverdb and makes sure they all process it. https://pagure.io/fedora-ci/monitor-gating In runs in our openshift cluster. I've not seen any errors from it in a long while... but I'm not sure if thats because everything has been working or because it isn't erroring properly. Anyhow, I think we should/can adjust it to not make big changelogs... kevin signature.asc Description: PGP signature ___ 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
Re: F38 DNF/RPM install errors due to header signatures
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 > 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 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
[Bug 2183876] perl-File-Map-0.71 is available
https://bugzilla.redhat.com/show_bug.cgi?id=2183876 Upstream Release Monitoring changed: What|Removed |Added Summary|perl-File-Map-0.70 is |perl-File-Map-0.71 is |available |available --- Comment #1 from Upstream Release Monitoring --- Releases retrieved: 0.71 Upstream release that is considered latest: 0.71 Current version/release in rawhide: 0.68-1.fc39 URL: https://metacpan.org/dist/File-Map Please consult the package updates policy before you issue an update to a stable branch: https://docs.fedoraproject.org/en-US/fesco/Updates_Policy/ More information about the service that created this bug can be found at: https://docs.fedoraproject.org/en-US/package-maintainers/Upstream_Release_Monitoring Please keep in mind that with any upstream change, there may also be packaging changes that need to be made. Specifically, please remember that it is your responsibility to review the new version to ensure that the licensing is still correct and that no non-free or legally problematic items have been added upstream. Based on the information from Anitya: https://release-monitoring.org/project/12648/ To change the monitoring settings for the project, please visit: https://src.fedoraproject.org/rpms/perl-File-Map -- You are receiving this mail because: You are on the CC list for the bug. https://bugzilla.redhat.com/show_bug.cgi?id=2183876 ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-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/perl-devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: F38 DNF/RPM install errors due to header signatures
Once upon a time, Stephen Smoogen 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 ___ 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
Re: F38 DNF/RPM install errors due to header signatures
On Mon, Apr 10, 2023 at 12:39 PM Stephen Smoogen 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 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: >>
Re: F38 DNF/RPM install errors due to header signatures
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 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@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
[Bug 2185525] perl-Business-ISBN-Data-20230410.001 is available
https://bugzilla.redhat.com/show_bug.cgi?id=2185525 Fedora Update System changed: What|Removed |Added Resolution|--- |ERRATA Status|MODIFIED|CLOSED Fixed In Version||perl-Business-ISBN-Data-202 ||30410.001-1.fc39 Last Closed||2023-04-10 10:41:48 --- Comment #2 from Fedora Update System --- FEDORA-2023-ee95a01dbe has been pushed to the Fedora 39 stable repository. If problem still persists, please make note of it in this bug report. -- You are receiving this mail because: You are on the CC list for the bug. https://bugzilla.redhat.com/show_bug.cgi?id=2185525 ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-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/perl-devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
[Bug 2185525] perl-Business-ISBN-Data-20230410.001 is available
https://bugzilla.redhat.com/show_bug.cgi?id=2185525 Fedora Update System changed: What|Removed |Added Status|ASSIGNED|MODIFIED --- Comment #1 from Fedora Update System --- FEDORA-2023-ee95a01dbe has been submitted as an update to Fedora 39. https://bodhi.fedoraproject.org/updates/FEDORA-2023-ee95a01dbe -- You are receiving this mail because: You are on the CC list for the bug. https://bugzilla.redhat.com/show_bug.cgi?id=2185525 ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-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/perl-devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
[Bug 2185525] perl-Business-ISBN-Data-20230410.001 is available
https://bugzilla.redhat.com/show_bug.cgi?id=2185525 Paul Howarth changed: What|Removed |Added Assignee|jples...@redhat.com |p...@city-fan.org Doc Type|--- |If docs needed, set a value Status|NEW |ASSIGNED -- You are receiving this mail because: You are on the CC list for the bug. https://bugzilla.redhat.com/show_bug.cgi?id=2185525 ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-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/perl-devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: F38 DNF/RPM install errors due to header signatures
> On Mon, Apr 10, 2023 at 12:16 AM Samuel Sieb > > 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 ___ 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
[Bug 2185525] New: perl-Business-ISBN-Data-20230410.001 is available
https://bugzilla.redhat.com/show_bug.cgi?id=2185525 Bug ID: 2185525 Summary: perl-Business-ISBN-Data-20230410.001 is available Product: Fedora Version: rawhide Status: NEW Component: perl-Business-ISBN-Data Keywords: FutureFeature, Triaged Assignee: jples...@redhat.com Reporter: upstream-release-monitor...@fedoraproject.org QA Contact: extras...@fedoraproject.org CC: jples...@redhat.com, ka...@ucw.cz, mspa...@redhat.com, p...@city-fan.org, perl-devel@lists.fedoraproject.org Target Milestone: --- Classification: Fedora Releases retrieved: 20230410.001 Upstream release that is considered latest: 20230410.001 Current version/release in rawhide: 20230331.001-1.fc39 URL: https://metacpan.org/dist/Business-ISBN-Data/ Please consult the package updates policy before you issue an update to a stable branch: https://docs.fedoraproject.org/en-US/fesco/Updates_Policy/ More information about the service that created this bug can be found at: https://docs.fedoraproject.org/en-US/package-maintainers/Upstream_Release_Monitoring Please keep in mind that with any upstream change, there may also be packaging changes that need to be made. Specifically, please remember that it is your responsibility to review the new version to ensure that the licensing is still correct and that no non-free or legally problematic items have been added upstream. Based on the information from Anitya: https://release-monitoring.org/project/2674/ To change the monitoring settings for the project, please visit: https://src.fedoraproject.org/rpms/perl-Business-ISBN-Data -- You are receiving this mail because: You are on the CC list for the bug. https://bugzilla.redhat.com/show_bug.cgi?id=2185525 ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-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/perl-devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
