$ 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 <email@example.com>" 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 <firstname.lastname@example.org>
Adding sysadmin team to cc list for expired release key.
Is this issue still valid?
Yes, this is still the case:
Fixed with 1.43
For Mageia 8:
There is already an isodumper-1.35-2.mga8 in Core/Updates repo! so updating the list:
Updated packages in core/updates_testing:
I have installed the isodumper and it launches OK, but this story of keys is beyond me. Leaving for others.
The following 2 packages are going to be installed:
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.
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.
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.
# 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 <email@example.com>" 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.
The server is now keyserver.ubuntu.com
Deleted /root/.gnupg, ran isodumper to write an m9 beta iso image ok.
Validating the update. Advisory committed to svn.
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?
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 ...
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
OK, Bug 31598, though it's rather poorly crafted due to my lack of knowledge in this area.
So.. this is an issue in a mga8 package that is kind of release blocker for mga9.
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
An update for this issue has been pushed to the Mageia Updates repository.