Hi,
on f38, I am unable to install any locally built package (signed with a local key, I have been using for many years):
# rpm -U xpetri-0.4.8-0.fc38.x86_64.rpm error: xpetri-0.4.8-0.fc38.x86_64.rpm: Header V4 RSA/SHA256 Signature, key ID a6b9312e: BAD error: xpetri-0.4.8-0.fc38.x86_64.rpm cannot be installed
# rpm -qip xpetri-0.4.8-0.fc38.x86_64.rpm error: xpetri-0.4.8-0.fc38.x86_64.rpm: Header V4 RSA/SHA256 Signature, key ID a6b9312e: BAD error: xpetri-0.4.8-0.fc38.x86_64.rpm: not an rpm package (or package manifest)
# dnf install xpetri-0.4.8-0.fc38.x86_64.rpm Last metadata expiration check: 1:30:47 ago on Tue 28 Feb 2023 06:25:45 AM CET. Dependencies resolved. ... 0.4.8-0.fc38 @commandline
... Installing dependencies: ... Downloading Packages: (1/6): XXX.rpm ... Total 1.2 MB/s | 130 kB 00:00 ... Problem opening package XXX.rpm ... The downloaded packages were saved in cache until the next successful transaction. You can remove cached packages by executing 'dnf clean packages'. Error: GPG check FAILED
Worse, after trying forcefully to install packages using rpm -U --nogpg this happens:
# rpm -qa gpg-pubkey-d651ff2e-5dadbbc1 gpg-pubkey-8ff214b4-3afa5d46 gpg-pubkey-a6b9312e-5227e975 gpg-pubkey-94843c65-5dadbc64 error: rpmdbNextIterator: skipping h# 5 Header V4 DSA/SHA1 Signature, key ID 8ff214b4: BAD Header SHA256 digest: OK Header SHA1 digest: OK error: rpmdbNextIterator: skipping h# 6 Header V3 RSA/SHA1 Signature, key ID d651ff2e: BAD Header SHA256 digest: OK Header SHA1 digest: OK gpg-pubkey-5323552a-6112bcdc ... => nogpg is not ignored, as it is supposed to be.
What are people supposed to do?
Ralf
On Tue, 2023-02-28 at 09:10 +0100, Ralf Corsépius wrote:
Hi,
on f38, I am unable to install any locally built package (signed with a local key, I have been using for many years):
"Many years" is likely the problem. It's probably using SHA-1 or DSA. See, for e.g., https://bugzilla.redhat.com/show_bug.cgi?id=2170878 . Those are now known to be insecure.
That bug covers some awkward problems with widely-used third parties still using insecure keys to sign their packages, which likely means this will get put off (one way or another) to at least Fedora 39. But for your own locally built packages, which are under your control, you can solve it permanently right now: generate a new key using a secure algorithm, and re-sign your packages with that.
What are people supposed to do?
See above.
Am 01.03.23 um 16:31 schrieb Adam Williamson:
On Tue, 2023-02-28 at 09:10 +0100, Ralf Corsépius wrote:
Hi,
on f38, I am unable to install any locally built package (signed with a local key, I have been using for many years):
"Many years" is likely the problem. It's probably using SHA-1 or DSA. See, for e.g., https://bugzilla.redhat.com/show_bug.cgi?id=2170878 . Those are now known to be insecure.
That bug covers some awkward problems with widely-used third parties still using insecure keys to sign their packages, which likely means this will get put off (one way or another) to at least Fedora 39. But for your own locally built packages, which are under your control, you can solve it permanently right now: generate a new key using a secure algorithm, and re-sign your packages with that.
What are people supposed to do?
See above.
Cf. the discussion on *-devel.
Due to this list not being open, I do not see any sense trying to furtherly discussing this issue here.
Only one point concerning you and this list: It seems obvious to me, this change was not tested at all. The effects of this change are desasterous,
Ralf
On Wed, 2023-03-01 at 20:07 +0100, Ralf Corsépius wrote:
Am 01.03.23 um 16:31 schrieb Adam Williamson:
On Tue, 2023-02-28 at 09:10 +0100, Ralf Corsépius wrote:
Hi,
on f38, I am unable to install any locally built package (signed with a local key, I have been using for many years):
"Many years" is likely the problem. It's probably using SHA-1 or DSA. See, for e.g., https://bugzilla.redhat.com/show_bug.cgi?id=2170878 . Those are now known to be insecure.
That bug covers some awkward problems with widely-used third parties still using insecure keys to sign their packages, which likely means this will get put off (one way or another) to at least Fedora 39. But for your own locally built packages, which are under your control, you can solve it permanently right now: generate a new key using a secure algorithm, and re-sign your packages with that.
What are people supposed to do?
See above.
Cf. the discussion on *-devel.
Due to this list not being open, I do not see any sense trying to furtherly discussing this issue here.
Only one point concerning you and this list: It seems obvious to me, this change was not tested at all. The effects of this change are desasterous,
Well, it was tested. That's why there's a bug report.
We don't have a secret Fedora where we try things behind a dark curtain and only put them out to the public if they work. That's not how Fedora works (and I doubt you'd like it if it did). Fedora is open, which means Fedora development is open, which means the way we test changes like this is...we make them (in Rawhide and/or Branched, obviously, not in stable releases!) and then anyone who's interested - whether they work for RH or not, whether they're part of Fedora QA or not - gets to try them out. That's what happened in this case, and folks (from all groups above) noticed this problem, so now we have a bug report and FESCo is on it and we're getting Google to fix their Chromium RPMs and the change is getting delayed. Isn't that how this should work?
On Wed, 2023-03-01 at 20:07 +0100, Ralf Corsépius wrote:
Am 01.03.23 um 16:31 schrieb Adam Williamson:
On Tue, 2023-02-28 at 09:10 +0100, Ralf Corsépius wrote:
Hi,
on f38, I am unable to install any locally built package (signed with a local key, I have been using for many years):
"Many years" is likely the problem. It's probably using SHA-1 or DSA. See, for e.g., https://bugzilla.redhat.com/show_bug.cgi?id=2170878 . Those are now known to be insecure.
That bug covers some awkward problems with widely-used third parties still using insecure keys to sign their packages, which likely means this will get put off (one way or another) to at least Fedora 39. But for your own locally built packages, which are under your control, you can solve it permanently right now: generate a new key using a secure algorithm, and re-sign your packages with that.
What are people supposed to do?
See above.
Cf. the discussion on *-devel.
Due to this list not being open, I do not see any sense trying to furtherly discussing this issue here.
Only one point concerning you and this list: It seems obvious to me, this change was not tested at all. The effects of this change are desasterous,
Annoying, yes. Disastrous, no. Easiest solution is the one already discussed, your old key is never going to be accepted again so it is time to make a new one. Solved.
Second solution is to revert Fedora's new paranoia that will detonate any old package. "sudo update-crypto-policies --set LEGACY" and get on with life for another Fedora release cycle... then the madmen will break things again. It is a cryptoweenie thing, break anything more than a few years old while autistically screeching "but it is INSECUUUURE!" Be thankful, as bad as Fedora can be, OpenSSH is worse; when they do the "INSECUUUUURE!" screeching they eventually remove every line of code that supported the now insecure crypto so you can't even rebuild from source to be able to still talk to that old box in a corner.
On Wed, 2023-03-01 at 19:39 -0600, John Morris wrote:
Second solution is to revert Fedora's new paranoia that will detonate any old package. "sudo update-crypto-policies --set LEGACY" and get on with life for another Fedora release cycle... then the madmen will break things again. It is a cryptoweenie thing, break anything more than a few years old while autistically screeching "but it is INSECUUUURE!"
"Security researchers have achieved the first real-world collision attack against the SHA-1 hash function, producing two different PDF files with the same SHA-1 signature. This shows that the algorithm's use for security-sensitive functions should be discontinued as soon as possible."
That was from *2017*.
https://www.computerworld.com/article/3173616/the-sha1-hash-function-is-now-...
On Wed, Mar 01, 2023 at 07:39:14PM -0600, John Morris wrote:
few years old while autistically screeching "but it is INSECUUUURE!" Be
I have been traveling and just got to this thread. This comment is entirely inappropriate -- and not in any case constructive or helpful. Please don't.
-
Adam Williamson -
John Morris -
Matthew Miller -
Ralf Corsépius