See https://bugs.mageia.org/show_bug.cgi?id=27354#c63 and 64 1) Log and window warn user checksum error, but dialogue say success 2) it is not clear to the user that the warning is about wrong checksum of the iso file (compared to what?) or that the read back does not match the file. Repeatability: always except for Mageia 8b1 isos, i think
Summary: Log and window warn user checksum error, but dialogue say success => Isodumper log and window warn user checksum error, but dialogue say success
*** Bug 27839 has been marked as a duplicate of this bug. ***
CC: (none) => micheelsen
All Mageia iso images except the mageia 8 beta 1 iso images use detached signatures. With a detached signature, the gpg --verify command must specify both the sig file and the data file in the command. For example ... gpg --verify Mageia-8-beta2-Live-Xfce-i586.iso.sha3.gpg Mageia-8-beta2-Live-Xfce-i586.iso.sha3 returns ... gpg: Signature made 2020-12-11T15:18:22 EST gpg: using RSA key B21076A0CBE4D93D66A9D08D835E41F4EDCA7A90 gpg: Good signature from "Mageia Release <release@mageia.org>" [full] The beta1 iso images mistakenly used signed copies of the file (with the signature embedded in the copy of the file). Ideally isodumper should first try with the command for an embedded signature, such as ... gpg --verify Mageia-8-beta2-Live-Xfce-i586.iso.sha3.gpg If that fails with ... gpg: no signed data gpg: can't hash datafile: No data then try with the command again specifying the data file ... gpg --verify Mageia-8-beta2-Live-Xfce-i586.iso.sha3.gpg Mageia-8-beta2-Live-Xfce-i586.iso.sha3 returns ... gpg: Signature made 2020-12-11T15:18:22 EST gpg: using RSA key B21076A0CBE4D93D66A9D08D835E41F4EDCA7A90 gpg: Good signature from "Mageia Release <release@mageia.org>" [full]
CC: (none) => davidwhodgins
Additionally, if there is no signature file, such as when using another image than Mageia Live(i.e the backup), it need to verify the read back against the image file instead.
Hello, I pushed 1.30 on git. It should manage the signatures detached or not. It should also display warning instead of success if signature check fails. Papoteur
Works OK when dumping 8 beta 2 isos. Is it tested dumping 8 beta 1 isos? (i have scrapped mine such isos...) I have not tested what happens if data or checksum is wrong. One severe bug: dumping Mageia-6-netinstall-nonfree-i586.iso and no sha file around, isodumper window vanishes and in terminal from where it started: Traceback (most recent call last): File "/usr/lib/python3.7/site-packages/isodumper/isodumper.py", line 909, in run self.handleevent() File "/usr/lib/python3.7/site-packages/isodumper/isodumper.py", line 866, in handleevent self.do_write() File "/usr/lib/python3.7/site-packages/isodumper/isodumper.py", line 461, in do_write self.warning() TypeError: 'str' object is not callable
I tested with an invalid sha3 file (copied the iso, sha3 and sha3.gpg file to a tmp directory, edited the sha3 file changing one byte of the sig). Same results as comment 5.
Also just noticed the terminal where I ran isodumper was stuck. The magiback program was still running (waiting for input, I think). Pressing ctrl+c in that window ... ^CException ignored in: <module 'threading' from '/usr/lib64/python3.7/threading.py'> Traceback (most recent call last): File "/usr/lib64/python3.7/threading.py", line 1307, in _shutdown lock.acquire() KeyboardInterrupt
Checked /var/log/magiback.log and it correctly has ... 2020-12-20 11:32:06,208 INFO Invalid signature for /tmp/tmp/Mageia-8-beta2-Live-Xfce-x86_64.iso.sha3 /!\The computed and stored sums don't match Ran the test again, this time using a hex editor to modify the gpg sig. Failed again as per comment 5. magiback.log has ... 2020-12-20 11:32:06,208 INFO Invalid signature for /tmp/tmp/Mageia-8-beta2-Live-Xfce-x86_64.iso.sha3 /!\The computed and stored sums don't match So magiback is working, it's just the gui that isn't handling the exceptions properly.
Hi, I have found how to fix this crash. But in the same time I have also found another problem in reporting success or not. But I didn't yet find the solution. Still working on that.
Good, keep up the work :)
Should be fixed, as said in another report, with 1.31 release, now on git.
With 1.33.
Resolution: (none) => FIXEDStatus: NEW => RESOLVED