Bug 29895 - hard coded key server pool.sks-keyservers.net is no longer available
Summary: hard coded key server pool.sks-keyservers.net is no longer available
Alias: None
Product: Mageia
Classification: Unclassified
Component: RPM Packages (show other bugs)
Version: 8
Hardware: All Linux
Priority: High major
Target Milestone: ---
Assignee: QA Team
QA Contact:
Whiteboard: MGA8-64-OK
Keywords: advisory, validated_update
Depends on:
Reported: 2022-01-15 22:22 CET by Dave Hodgins
Modified: 2023-02-27 21:28 CET (History)
7 users (show)

See Also:
Source RPM: isodumper-1.35-1.mga8.src.rpm
Status comment:


Description Dave Hodgins 2022-01-15 22:22:37 CET
$ host pool.sks-keyservers.net
Host pool.sks-keyservers.net not found: 3(NXDOMAIN)
$ grep -Ir recv /usr/lib/python3.8/site-packages/isodumper/*
/usr/lib/python3.8/site-packages/isodumper/raw_write.py:                gpg.recv_keys('pool.sks-keyservers.net', mageia_keyid)

As per bug 29470 the ubuntu key server is working, though our release key
is currently expired.
[root@x3 ~/.gnupg]# gpg  --refresh-keys 0xEDCA7A90
gpg: refreshing 1 key from hkp://keyserver.ubuntu.com
gpg: key 835E41F4EDCA7A90: "Mageia Release <release@mageia.org>" not changed
gpg: Total number processed: 1
gpg:              unchanged: 1
[root@x3 ~/.gnupg]# gpg  --list-keys 0xEDCA7A90
pub   rsa4096 2012-04-18 [SCEA] [expired: 2022-01-10]
uid           [ expired] Mageia Release <release@mageia.org>
Comment 1 Dave Hodgins 2022-01-15 22:23:40 CET
Adding sysadmin team to cc list for expired release key.

CC: (none) => sysadmin-bugs

Comment 2 David GEIGER 2023-02-04 13:51:01 CET
Is this issue still valid?

CC'ing papoteur

CC: (none) => yves.brungard_mageia

Comment 3 papoteur 2023-02-04 14:17:37 CET
Yes, this is still the case:
Comment 4 papoteur 2023-02-05 14:50:00 CET
Fixed with 1.43
Comment 5 papoteur 2023-02-05 14:50:19 CET
See previous

Resolution: (none) => FIXED

Comment 6 papoteur 2023-02-05 16:29:28 CET
For Mageia 8:


Resolution: FIXED => (none)
Assignee: geiger.david68210 => qa-bugs

Comment 7 David GEIGER 2023-02-05 18:42:12 CET
There is already an isodumper-1.35-2.mga8 in Core/Updates repo! so updating the list:

Updated packages in core/updates_testing:

from SRPMS:

CC: (none) => geiger.david68210

Comment 8 Herman Viaene 2023-02-21 16:11:44 CET
I have installed the isodumper and it launches OK, but this story of keys is beyond me. Leaving for others.

CC: (none) => herman.viaene

Comment 9 Brian Rockwell 2023-02-22 16:19:37 CET
MGA8 Plasma 

The following 2 packages are going to be installed:

- isodumper-1.35-2.1.mga8.noarch
- isodumper-qt-1.35-2.1.mga8.noarch

Target Device: General USB Flash Disk (/dev/sdb) 14.566 GiB
Image : /home/brian/Downloads/iso/Mageia-9-beta1-Live-Xfce-i586/Mageia-9-beta1-Live-Xfce-i586.iso
Executing copy from /home/brian/Downloads/iso/Mageia-9-beta1-Live-Xfce-i586/Mageia-9-beta1-Live-Xfce-i586.iso to /dev/sdb
Image Mageia-9-beta1-Live-Xfce-i586.iso successfully written to /dev/sdb
Bytes written: 2994075648

The sha3 sum check is OK but the signature can't be found
Added persistent partition

I didn't wireshark it, so can't tell connections.  But this version works.

CC: (none) => brtians1
Whiteboard: (none) => MGA8-64-OK

Comment 10 Thomas Andrews 2023-02-24 16:13:13 CET
I too updated isodumper-qt, and of course isodumper on a Plasma system.

I dumped the Mageia 8 Live Plasma iso to a usb stick, creating an encrypted persistent partition. Then I took it over to my HP Pavilion 15 laptop (EFI, usb 3.0 ports) and booted it. I was asked for the password, and it was accepted.

After the boot process completed, I set up the wifi connection, disabled the screen locker, and shut things back down again. Upon rebooting, the machine went straight to the Plasma desktop, with wifi enabled, as expected. Another boot, this time using an incorrect password, asked me for the password again, and continued booting when it was correct.

So, confirming Brian's OK, and Validating.

Keywords: (none) => validated_update
CC: (none) => andrewsfarm

Comment 11 Dave Hodgins 2023-02-25 00:33:47 CET
Removing the ok/validation. It fails to fetch the key.
After renaming /root/.gnupg ...

Target Device: SanDisk Ultra USB 3.0 (/dev/sdh) 114.609 GiB
Image : /s3/m8/Mageia-8-Live-Xfce-x86_64/Mageia-8-Live-Xfce-x86_64.iso
Executing copy from /s3/m8/Mageia-8-Live-Xfce-x86_64/Mageia-8-Live-Xfce-x86_64.iso to /dev/sdh
Image Mageia-8-Live-Xfce-x86_64.iso successfully written to /dev/sdh
Bytes written: 2943299584
Invalid signature for /s3/m8/Mageia-8-Live-Xfce-x86_64/Mageia-8-Live-Xfce-x86_64.iso.sha3
The validation of the GPG signature failed !
The integrity of the ISO image could not be verified.

Looking into it to see why.

Keywords: validated_update => (none)
Whiteboard: MGA8-64-OK => (none)

Comment 12 Dave Hodgins 2023-02-25 01:44:19 CET
# gpg --keyserver  pgp.mit.edu  --recv-keys 835E41F4EDCA7A90
gpg: keyserver receive failed: No keyserver available
# gpg --keyserver  keyserver.ubuntu.com  --recv-keys 835E41F4EDCA7A90
gpg: key 835E41F4EDCA7A90: public key "Mageia Release <release@mageia.org>" imported
gpg: Total number processed: 1
gpg:               imported: 1

I don't like using a key server run by another distribution, but it seems to
be one of the few still working with older versions of pgp and with gpg.
Comment 13 papoteur 2023-02-25 22:55:05 CET
New packages:


The server is now keyserver.ubuntu.com
Comment 14 Dave Hodgins 2023-02-25 23:00:38 CET
Tested isodumper-1.35-2.2.mga8
Deleted /root/.gnupg, ran isodumper to write an m9 beta iso image ok.
Validating the update. Advisory committed to svn.

Keywords: (none) => advisory, validated_update
Whiteboard: (none) => MGA8-64-OK

Comment 15 Thomas Andrews 2023-02-26 00:30:49 CET
According to https://bugs.mageia.org/show_bug.cgi?id=29470#c1, Mageiasync may also be affected by this. Does it need to be rebuilt, too?
Comment 16 Dave Hodgins 2023-02-26 01:05:25 CET
Yes mageiasync needs to be changed too, though for beta 1 since the signature
files contain signed compressed copies of the checksum files rather then
detached signatures which is what was supposed to be created. Too late for
beta 1, but a release blocker for the rc and final iso images.

While isodumper works with either, signed compressed copies or detached
signatures, mageiasync only works for checking detached signatures, hence
it fails even if the key has already been imported to gpg.

Please open a bug report for mageiasync, though since it's only for use by
qa iso testers who can be instructed to manually import the key, it's a
much lower priority then isodumper.

To see the difference, cd to the directory for the Xfce x86_64 iso for m9 beta1
$ gpg Mageia-9-beta1-Live-Xfce-x86_64.iso.sha3.gpg
File 'Mageia-9-beta1-Live-Xfce-x86_64.iso.sha3' exists. Overwrite? (y/N)

With a detached signature as has been used in prior releases, including m8,
instead of wanting to overwrite the checksum file, it will go on to the
next step of asking which file the signature should be used to verify.

$ gpg Mageia-8-Live-Xfce-x86_64.iso.sha3.gpg
gpg: WARNING: no command supplied.  Trying to guess what you mean ...
Detached signature.
Please enter name of data file: Mageia-8-Live-Xfce-x86_64.iso.sha3
gpg: Signature made 2021-02-24T14:49:12 EST
gpg:                using RSA key B21076A0CBE4D93D66A9D08D835E41F4EDCA7A90
Comment 17 Thomas Andrews 2023-02-26 02:39:20 CET
OK, Bug 31598, though it's rather poorly crafted due to my lack of knowledge in this area.
Comment 18 Morgan Leijström 2023-02-26 09:57:05 CET
So.. this is an issue in a mga8 package that is kind of release blocker for mga9.

CC: (none) => fri
Severity: normal => major
Priority: Normal => High

Comment 19 Dave Hodgins 2023-02-26 17:18:24 CET
The problem is with the way the checksum files were signed for the m9 beta 1 iso
files. The issue of not using detached signatures will be a blocker, not this
bug report.
Comment 20 Mageia Robot 2023-02-27 21:28:35 CET
An update for this issue has been pushed to the Mageia Updates repository.


Resolution: (none) => FIXED

Note You need to log in before you can comment on or make changes to this bug.