I'm trying to install the Mageia 8 by putting the ISO on a USB stick and Isodumper tells me at the end of the operation : ┌──── │ Incorrect signature for Mageia-8-x86_64.iso.sha3 └──── It must be said that, on page : ┌──── │ https://www.mageia.org/en/downloads/get/?q=Mageia-8-x86_64.iso └──── it is recommended to run : ┌──── │ sha3sum -c Mageia-8-x86_64.iso.sha3 └──── whereas this command does not exist on the Mageia 7 since only the ones provided are : ┌──── │ sha3-224sum sha3-256sum sha3-384sum sha3-512sum sha384sum └──── I run: ┌──── │ $ sha3-512sum -c Mageia-8-x86_64.iso.sha3 └──── and the answer was: ┌──── │ Mageia-8-x86_64.iso: OK └──── In addition, here are the other checks carried out: ┌──── │ $ md5sum -c Mageia-8-x86_64.iso.md5 │ Mageia-8-x86_64.iso: Success story │ $ sha512sum -c Mageia-8-x86_64.iso.sha512 │ Mageia-8-x86_64.iso: Success story └──── (note "Successful" instead of "OK" above). In addition : ┌──── │ $ gpg --verify Mageia-8-x86_64.iso.sha512.gpg Mageia-8-x86_64.iso.sha512 │ gpg: Signature made on Wed. Feb. 24, 2021 20:49:46 CET │ gpg: with RSA key B21076A0CBE4D93D66A9D08D835E41F4EDCA7A90 │ gpg: Good signature of "Mageia Release <release@mageia.org>" [unknown]. │ gpg: Warning: this key is not certified with a trusted signature. │ gpg: There is no indication that the signature belongs to its owner. │ Main key imprint: B210 76A0 CBE4 D93D 66A9 D08D 835E 41F4 EDCA 7A90 └──── So I deduce that the ISO image that I downloaded is not corrupted.
we added the sha3 method recently on download page (even if file was provide already in mga7), I think I will just remove it as it's confusing
CC: (none) => atelier-bugs
(In reply to Manuel Hiebel from comment #1) > we added the sha3 method recently on download page (even if file was provide > already in mga7), I think I will just remove it as it's confusing No, please wait. It seems this is ISOdumper which complains about wrong sha3... papoteur should see that.
CC: (none) => ouaurelien
CC: (none) => yves.brungard_mageia
well in mageia8 there is no sha3sum command, I don't know if it's exist somewhere else and we need to modify php code anyway as the file doesn't correspond to the command http://gitweb.mageia.org/web/www/tree/en/downloads/get/index.php#n260
From isodumper on my system ... Target Device: SanDisk Ultra USB 3.0 (/dev/sdf) 114.609 GiB Image : /s3/m8/Mageia-8-x86_64/Mageia-8-x86_64.iso Executing copy from /s3/m8/Mageia-8-x86_64/Mageia-8-x86_64.iso to /dev/sdf Image Mageia-8-x86_64.iso successfully written to /dev/sdf Bytes written: 4499220480 The sha3 sum check is OK and the sum is signed # rpm -q isodumper isodumper-1.33-1.mga7 # rpm -q sha3sum sha3sum-1.1.5-1.mga7 # sha3-512sum -c Mageia-8-x86_64.iso.sha3 Mageia-8-x86_64.iso: OK # rpm -q gnupg2 gnupg2-2.2.19-1.mga7 # gpg --verify Mageia-8-x86_64.iso.sha3.gpg Mageia-8-x86_64.iso.sha3 gpg: Signature made 2021-02-24T14:49:46 EST gpg: using RSA key B21076A0CBE4D93D66A9D08D835E41F4EDCA7A90 gpg: Good signature from "Mageia Release <release@mageia.org>" [unknown] gpg: WARNING: This key is not certified with a trusted signature! gpg: There is no indication that the signature belongs to the owner. Primary key fingerprint: B210 76A0 CBE4 D93D 66A9 D08D 835E 41F4 EDCA 7A90 # gpg --list-key EDCA7A90 pub rsa4096 2012-04-18 [SCEA] [expires: 2022-01-10] B21076A0CBE4D93D66A9D08D835E41F4EDCA7A90 uid [ unknown] Mageia Release <release@mageia.org> Now with isodumper, it's checking the contents of the usb drive that it reads back from the drive after copying it there. If that fails, is the drive too small? Were there write or read errors? I agree the files are named badly.
CC: (none) => davidwhodgins
The script I use to verify the sums of all of the iso files ... #!/bin/bash for dir in /s3/m8/Mageia-8*/ ; do printf "%s\n" "dir=$dir" cd "$dir" for file in *.md5 ; do printf "%s\n" "md5 check ${dir}$file " && md5sum -c "$file" done for file in *.sha3 ; do printf "%s\n" "sha3-512sum check ${dir}$file " && sha3-512sum -c "$file" done for file in *.sha512 ; do printf "%s\n" "sha512 check ${dir}$file " && sha512sum -c "$file" done cd .. done And the output ... $ ./checksum dir=/s3/m8/Mageia-8-i586/ md5 check /s3/m8/Mageia-8-i586/Mageia-8-i586.iso.md5 Mageia-8-i586.iso: OK sha3-512sum check /s3/m8/Mageia-8-i586/Mageia-8-i586.iso.sha3 Mageia-8-i586.iso: OK sha512 check /s3/m8/Mageia-8-i586/Mageia-8-i586.iso.sha512 Mageia-8-i586.iso: OK dir=/s3/m8/Mageia-8-Live-GNOME-x86_64/ md5 check /s3/m8/Mageia-8-Live-GNOME-x86_64/Mageia-8-Live-GNOME-x86_64.iso.md5 Mageia-8-Live-GNOME-x86_64.iso: OK sha3-512sum check /s3/m8/Mageia-8-Live-GNOME-x86_64/Mageia-8-Live-GNOME-x86_64.iso.sha3 Mageia-8-Live-GNOME-x86_64.iso: OK sha512 check /s3/m8/Mageia-8-Live-GNOME-x86_64/Mageia-8-Live-GNOME-x86_64.iso.sha512 Mageia-8-Live-GNOME-x86_64.iso: OK dir=/s3/m8/Mageia-8-Live-Plasma-x86_64/ md5 check /s3/m8/Mageia-8-Live-Plasma-x86_64/Mageia-8-Live-Plasma-x86_64.iso.md5 Mageia-8-Live-Plasma-x86_64.iso: OK sha3-512sum check /s3/m8/Mageia-8-Live-Plasma-x86_64/Mageia-8-Live-Plasma-x86_64.iso.sha3 Mageia-8-Live-Plasma-x86_64.iso: OK sha512 check /s3/m8/Mageia-8-Live-Plasma-x86_64/Mageia-8-Live-Plasma-x86_64.iso.sha512 Mageia-8-Live-Plasma-x86_64.iso: OK dir=/s3/m8/Mageia-8-Live-Xfce-i586/ md5 check /s3/m8/Mageia-8-Live-Xfce-i586/Mageia-8-Live-Xfce-i586.iso.md5 Mageia-8-Live-Xfce-i586.iso: OK sha3-512sum check /s3/m8/Mageia-8-Live-Xfce-i586/Mageia-8-Live-Xfce-i586.iso.sha3 Mageia-8-Live-Xfce-i586.iso: OK sha512 check /s3/m8/Mageia-8-Live-Xfce-i586/Mageia-8-Live-Xfce-i586.iso.sha512 Mageia-8-Live-Xfce-i586.iso: OK dir=/s3/m8/Mageia-8-Live-Xfce-x86_64/ md5 check /s3/m8/Mageia-8-Live-Xfce-x86_64/Mageia-8-Live-Xfce-x86_64.iso.md5 Mageia-8-Live-Xfce-x86_64.iso: OK sha3-512sum check /s3/m8/Mageia-8-Live-Xfce-x86_64/Mageia-8-Live-Xfce-x86_64.iso.sha3 Mageia-8-Live-Xfce-x86_64.iso: OK sha512 check /s3/m8/Mageia-8-Live-Xfce-x86_64/Mageia-8-Live-Xfce-x86_64.iso.sha512 Mageia-8-Live-Xfce-x86_64.iso: OK dir=/s3/m8/Mageia-8-x86_64/ md5 check /s3/m8/Mageia-8-x86_64/Mageia-8-x86_64.iso.md5 Mageia-8-x86_64.iso: OK sha3-512sum check /s3/m8/Mageia-8-x86_64/Mageia-8-x86_64.iso.sha3 Mageia-8-x86_64.iso: OK sha512 check /s3/m8/Mageia-8-x86_64/Mageia-8-x86_64.iso.sha512 Mageia-8-x86_64.iso: OK If isodumper is saying the sha3 sum doesn't match, that means that what it read back from the usb stick failed to match the value from the .sha3 file. The contents of the iso file on disk may be ok, but what it read back from the usb stick after writing it, failed to match. Checking the sha3 sum with sha3-512sum -c "$file" will tell you if the file on the hard drive is ok or not. The isodumper output is telling you if what is on the usb stick is ok or not.
Just fyi, the file names are confusing mostly because the actual commands are too. [dave@x3 m8]$ rpm -q -f /usr/bin/sha512sum coreutils-8.31-1.mga7 [dave@x3 m8]$ rpm -q -f /usr/bin/sha3-512sum sha3sum-1.1.5-1.mga7
Just to add to the confusiong, the sha512sum command is for the sha2 sum.
CC: (none) => fri
*** Bug 28473 has been marked as a duplicate of this bug. ***
CC: (none) => philippe.mallocci
Assigning to isodumper maintainer. sha3 checksum error at end of writing to USB drive message should be improved to a better user friendly, as, for example: "The USB drive seems defective. Isodumper has controlled the checksum of the written image ISO to your USB drive and it does not correspond to the one you have downloaded. Please change your USB Key and try again.".
Version: 8 => CauldronComponent: Release (media or process) => New RPM package requestSummary: Incorrect Signature for Mageia-8-x86_64.iso.sha3 => Isodumper should improve reporting errors to user: incorrect sha3 key at end refers to errors on USB drivePriority: Normal => HighWhiteboard: (none) => MGA7TOO MGA8TOOAssignee: bugsquad => yves.brungard_mageiaHardware: x86_64 => AllSeverity: normal => majorSource RPM: (none) => isodumper-1.33-1.mga8.src.rpm
(In reply to Aurelien Oudelet from comment #9) > Assigning to isodumper maintainer. > sha3 checksum error at end of writing to USB drive message should be > improved to a better user friendly, as, for example: > > "The USB drive seems defective. Isodumper has controlled the checksum of the > written image ISO to your USB drive and it does not correspond to the one > you have downloaded. Please change your USB Key and try again.". But isn't the problem instead due to the fact Isodumper runs `sha3sum -c Mageia-8-x86_64.iso.sha3` and Mageia doesn't provide any `sha3sum` (but provides e.g. `sha3-512sum`).
Isodumper doesn't call any of the sha commands. It uses python functions to calculate the sha3_512 value of what it reads from the usb drive (after it has finshed copying the iso to the usb drive ) and compares that the the value from the file.
Idea: Simply one message line per test of checksummin and signature separately: Verified against checksum file: OK / Wrong / File not found Checksum file gpg signature: OK / Invalid / expired, not found, whatever...
Incorrectly forwarded. Fixing this.
Component: New RPM package request => RPM Packages
(In reply to Aurelien Oudelet from comment #9) > "The USB drive seems defective ... Please change your USB Key and try again.". FAKE NEWS!!! All this agreement on failed writes and defective USB keys is a *huge* red herring. I'd wager that in 99% of cases, users' flash drives are fine. It's isodumper's final step that failing! Borrowing OP's stylish text brackets (brilliant idea, David!) here's my output and experience: ┌──── │ Image Mageia-8-x86_64.iso successfully written to /dev/sdc │ Bytes written: 4499220480 │ Invalid signature for /home/john/.../Mageia-8-x86_64.iso.sha3 │ The signature of the sum is false ! └──── As you can see, I also got the checksum failure error message. But I have the utmost confidence in the health of my USB key and didn't believe it. So I manually checked what had actually been written to the device... ┌──── │ $ cmp -n $( stat -c '%s' Mageia-8-x86_64.iso ) Mageia-8-x86_64.iso /dev/sdc │ $ │ $ head -c $( stat -c '%s' Mageia-8-x86_64.iso ) /dev/sdc | sha3-512sum │ F3DADD10FCB64BCBAC55C91B9270521520D70195BDF27CEB414E0F4960863D8C3C0EC4E\ │ CDF5AFF87868FA8133BE1A58EFB58239DDC845F5A598DD0441EF685F3 - │ $ │ $ cat Mageia-8-x86_64.iso.sha3 │ F3DADD10FCB64BCBAC55C91B9270521520D70195BDF27CEB414E0F4960863D8C3C0EC4E\ │ CDF5AFF87868FA8133BE1A58EFB58239DDC845F5A598DD0441EF685F3 Mageia-8-\ │ x86_64.iso └──── ...and as you can see, cmp's byte-for-byte comparison of my downloaded image and what was written to my USB key returned no discrepancies. Next, sending the image's byte-count out through head and piping the results directly into sha3-512sum returned *exactly* the expected value. No errors here! I've since used the image on that key to perform a clean install on two machines. Both boxes -- one of which I'm writing this very post from -- are running happily, and so far, forgiving a handful of minor hiccups, Mageia 8 is GREAT!!! CONCLUSION: There's nothing wrong with isodumper's ability to transfer the image, but something is *seriously* borked with the way it runs the checksum algorithm in its final stage. Hopefully not too many Mageians needlessly toss out perfectly good flash drives because of this false error message, and whatever is wrong definitely needs to be fixed ASAP.
CC: (none) => johnltw
Whoops. Regarding OP's stylish text brackets, I meant: Brilliant idea, *Denis*! Not 'David'. Excusez-moi. :-(
Oh, and lastly, regarding what a potentially better error message might look like in the event the write *legitimately* fails, my suggestion would be something to the effect of: ┌──── │ Checksum failure! The signature of the transferred image │ does not match /<location>/Mageia-8-x86_64.iso.sha3 └──── Note also that a space character ' ' does *not* precede an exclamation mark '!' (or '?' or ':') in English as it does in French. ;-)
There are two tests: 1) Checksumming: do the checksum in checksum file match a checksumming of the content read back from device? Result i.e: Correct / WRONG / device read error / No checksum file 2) gpg key for checksum file: Valid / Old / checksum file is missing / .. maybe just forward message from gpg if all is not OK, se example output at bottom of comment 0 In both cases there may be several different errors. The results 1) and 2) should be reported separately. (a short suggestion in my comment 12) Now the gpg check fail but Isodumper generate a message that users understand like it is the checksumming that dont match. (In reply to John L. ten Wolde from comment #14) > It's isodumper's final step that failing! Yes: how it report to user.
Hello, To be clear. The actual problem is that the Mageia's key has expired. With recently implementation of isodumper, it doesn't reload the key when it is already present, even if the key is expired. After that the check on signature fails. You can read the message, it speaks only of signature. Isodumper reports nothing about sum checking in this case, because it is a nonsense to check the sum against a file which is presumed as badly signed. Now, I have submitted a fix that checks the expiration date and reload the key if the expiration date is over. This doesn't prevent the case when network is not reachable at this time, but will save most of false alerts.
God the key loading get fixed. Still the message wording is not clear. A checksum itself is one kind of signature, and stating "signature is false" can be understood as "checksum did not match" - many users read it that way.
(In reply to Morgan Leijström from comment #19) > A checksum itself is one kind of signature, and stating "signature is false" > can be understood as "checksum did not match" - many users read it that way. Agreed. That was exactly my impression, in fact. @papoteur: Thank you for your explanation. I never would have imagined there were so many wheels within wheels at play...
Summary: Isodumper should improve reporting errors to user: incorrect sha3 key at end refers to errors on USB drive => Isodumper should improve reporting errors to user
OK, now that I have a better -- yet still limited -- understanding of what the real issue is, here are some suggestions for the (English) messaging regarding the signature error that would have been *much* clearer to me as a humble end user: ┌──── │ Validation of PGP signature failed! │ The integrity of the ISO image could not be verified. └──── Or alternatively, with direct references to the files in question: ┌──── │ Failed to validate PGP signature of /<location>/Mageia-X.iso.FOO.gpg │ could not verify integrity of /<location>/Mageia-X.iso └──── As Morgan pointed out in Comment 19, the word "signature", and I'll also add "fingerprint", can be regarded as loose synonyms for "checksum". Whatever message is ultimately decided on, it's imperative that "signature" be qualified by "PGP" for the sake of clarity. And as he also stated back in Comment 17, it would be *incredibly* helpful if an operation that fails reported *why* it did so ("Valid / Old / checksum file is missing / .. maybe just forward message from gpg if all is not OK"). Anyway, pressing on as a humble end user, it seems counter-intuitive to me that this PGP-signature check should be the last step in the operation. Shouldn't it be the *first* step? ┌──── │ Target Device: Kingston DataTraveler 2.0 (/dev/sdc) 7.520 GiB │ Image : /home/john/.../Mageia-8-x86_64.iso * │ Testing image integrity... Please wait. * │ Validation of PGP signature failed! * │ The integrity of the ISO image could not be verified. └──── Honestly, if it errors out, I would then expect a bit of interaction on isodumper's part (perhaps in the form of a modal dialogue?): ┌──── │ WARNING: Could not authenticate the integrity of the ISO image and/or │ its checksum(s). Either may have been tampered with by a third party. │ │ Proceed with writing the image anyway? │ │ [ yes ] [ NO! ] └──── Verifying that the image copied correctly by way of its checks at the *end* of the process makes perfect sense to me, but checking its PGP after the fact is confusing and seems completely out of place.
Hello, I modified the message of the invalid signature. I wait a little to catch some translations before asking for update. The idea of checking the signature at start is pertinent, but need to modify the logic of the application. I don't want to do this for now because I prefer that the update comes quickly.
That priority is good. Thank you :)
Is it getting built soon?
isodumper-1.34-1.mga7 isodumper-1.34-1.mga8 are now built.
Assignee: yves.brungard_mageia => qa-bugs
Version: Cauldron => 8Whiteboard: MGA7TOO MGA8TOO => MGA7TOO
Bug seem fixed and two new created as a bonus... Test on mga7-64, writing mga8 Live Plasma to a SD card in USB2 adapter in a USB3 port, with persistent partition, encrypted. SD card: Sandisk Extreme V30 MicroSD XC1 U3 A1 64GB __Results: Good: No complaint on checksum nor signature: "The sha3 sum check is OK and the sum is signed" Fault 1: Next line reads: "Error 4 while doing persistent partition: Device /dev/sdc3 doesn't exist or access denied."" An earlier mga8 ISO have been stored by Isodumper a month or so ago without that error. I do not think i have ever seen that before, ad i have made maybe fourty "dumps". Fault 2: Despite that error, the popup dialogue tell user it succeeded! I have not tested the resulting content on card. Excerpt from journal: mar 21 22:59:53 svarten.tribun kernel: sdc: sdc1 sdc2 mar 21 22:59:53 svarten.tribun magiback[15065]: Kommando (m för hjälp): Partitionstyp mar 21 22:59:53 svarten.tribun magiback[15065]: p primär (2 primär, 0 utökat, 2 ledigt) mar 21 22:59:53 svarten.tribun magiback[15065]: e utökad (behållare för logiska partitioner) mar 21 22:59:53 svarten.tribun magiback[15065]: Välj (standard p): Partitionsnummer (3,4, standardvärde 3): Första sektorn (7031732-124735487, standardvärde 70328> mar 21 22:59:53 svarten.tribun magiback[15065]: Skapad en ny partition 3 av typen ”Linux” med storlek 56,1 GiB. mar 21 22:59:54 svarten.tribun magiback[15065]: Kommando (m för hjälp): Partitionstabellen har ändrats. mar 21 22:59:54 svarten.tribun magiback[15065]: Anropar ioctl() för att läsa om partitionstabellen. mar 21 22:59:54 svarten.tribun magiback[15065]: Synkroniserar diskar. mar 21 22:59:54 svarten.tribun plasmashell[25886]: file:///usr/lib64/qt5/qml/QtQuick/Controls/Button.qml:99: TypeError: Type error mar 21 22:59:56 svarten.tribun kernel: sdc: detected capacity change from 63864569856 to 0
Assignee: qa-bugs => yves.brungard_mageiaSource RPM: isodumper-1.33-1.mga8.src.rpm => isodumper-1.34-1.mga8.src.rpm
With isodumper-1.34-1.mga7, just the tests that need feedback. All other tests ok. ================================================================== With neither the sha3 sum or it's gpg signature present, that results in ... The sha3 sum check is OK but the signature can't be found Why is it saying the sha3 sum check is OK? Is it doing an sha3 sum of both what's being read from the on disk iso to what's being read back from the usb stick? If that's what it's doing, it should be saying explicitly that the sha3sum of what's been read from the usb drive matches the sha3sum of what's been read from the disk drive, and should have a separate message to indicate if that sha3sum matches whats in the sha3sum file. We need it make it very clear that what's been read back from the usb stick matches what's in the iso file on disk, and that it's the sha3 sum file that it either doesn't match with, or that the sha3 sum file can not be found. ================================================================== With the sha3 sum present, and an altered gpg signature, that results in ... Invalid signature for /s3/m8/dumptest/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. (used a hex editor to alter 1 bit in the sig file for the above test) It should be saying the sha3 sums match but the gpg signature check of the sha3 sum file failed. ==================================================================
Keywords: (none) => feedback
Some additional changes I would like to see so the user interface reflects what is being done and in what order, though these changes may be considered for a future update. The option to Backup the device should be immediately after the Device selection, with additional text to indicate it's optional. Change the text "Write Image" to "Select iso" Rename the field Key to Passphrase, since it is requesting an encryption passphrase, not a gpg key id (though that could be a future option). Add a button to toggle displaying the typed in Passphrase. Move the button "Write to Device" to a new line after the line with the option to encrypt the device, since the option to add an encrypted persistent partition must be chosen before selecting the "Write to Device" button. The text "Format the device in FAT, exFAT, NTFS or ext:" should be changed to "Format the entire device in FAT, exFAT, NTFS or ext:" It should have a horizontal line the full width of the dialog box, both before and after it to indicate it's completely separate operation. As it is currently displayed, it could easily be interpreted as applying only to the persistent partition. I agree that the key expiration date and checking of the signature for the sha3sum file should be done before writing the device with the results displayed prior to starting writing the iso. Rather then stopping the writing on failure, it's probably ok to just display a warning that the local copy of the key has expired or a very bold WARNING that the verification of the sha3 file failed.
(In reply to Dave Hodgins from comment #29) > Some additional changes I would like to see so the user interface > reflects what is being done and in what order, though these changes may > be considered for a future update. Yes, I have suggested: https://bugs.mageia.org/show_bug.cgi?id=27744#c4
(In reply to Dave Hodgins from comment #28) > With isodumper-1.34-1.mga7, just the tests that need feedback. > All other tests ok. > > ================================================================== > > With neither the sha3 sum or it's gpg signature present, that results in ... > The sha3 sum check is OK but the signature can't be found > > Why is it saying the sha3 sum check is OK? This absolutely not what it is forseen nor what I get. In this case, the computed sum is written in the logview. > ================================================================== > > With the sha3 sum present, and an altered gpg signature, that results in ... > Invalid signature for /s3/m8/dumptest/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. > > (used a hex editor to alter 1 bit in the sig file for the above test) > > It should be saying the sha3 sums match but the gpg signature check of > the sha3 sum file failed. > ================================================================== No, I considered that if the file with the sum is proven to be false against the signature, the comparison shouldn't be reported. > Add a button to toggle displaying the typed in Passphrase. I already considered that, but the graphical library doesn't allow that. 1.35 is coming for error 2 reported by Morgan. For error 1, this is an error in external part, what I can do is only reporting it.
isodumper-1.35-1.mga7 isodumper-1.35-1.mga8 are now built.
QA Contact: (none) => qa-bugs
(In reply to papoteur from comment #31) > I considered that if the file with the sum is proven to be false against > the signature, the comparison shouldn't be reported. Consider cases: A) Content provided by other entities, with checksum files but without signing. It is still important to verify the dump to stick. B) User performs backup of a stick using i.e IsoDumper, and create a checksum file to verify it later when put on a stick again. (BTW IsoDumper copuld create a checksum file when it backs up a stick. I have not tried if it do.) > 1.35 is coming for error 2 reported by Morgan. For error 1, this is an error > in external part, what I can do is only reporting it. I dont know but this time it in total just worked OK :) I have not tested with initially non-updated keys. Bedtime.
(In reply to Morgan Leijström from comment #33) > (In reply to papoteur from comment #31) > > I considered that if the file with the sum is proven to be false against > > the signature, the comparison shouldn't be reported. > > Consider cases: > > A) Content provided by other entities, with checksum files but without > signing. It is still important to verify the dump to stick. > > B) User performs backup of a stick using i.e IsoDumper, and create a > checksum file to verify it later when put on a stick again. (BTW IsoDumper > copuld create a checksum file when it backs up a stick. I have not tried if > it do.) > When no checksum is present, the computed sum from what is dumped is reported. If checksum is present without signature, the comparison is done and reported.
Source RPM: isodumper-1.34-1.mga8.src.rpm => isodumper-1.35-1.mga8.src.rpm
Points A and B are answered, thus reassigning to QA
I downloaded to same folder: Mageia-Cauldron-netinstall-nonfree-x86_64.iso Mageia-Cauldron-netinstall-nonfree-x86_64.iso.sha512 When i let Isodumper put the .iso on the stick, i expected it to try to use the .iso.sha512 to verify it, but it did not. Instead it wrote out the sum: Sha3-summa: 4C3121EE9995523A96986A6FE77E6F405B0B6CC2C405A582128DCE9847E36DB38D441F46105462A8A8A3ACB3F969AC620649134A68F55B6D6D415B43F23B0D0D $ sha512sum -c Mageia-Cauldron-netinstall-nonfree-x86_64.iso.sha512 Mageia-Cauldron-netinstall-nonfree-x86_64.iso: OK $ cat Mageia-Cauldron-netinstall-nonfree-x86_64.iso.sha512 7a24e84b0c1f326d6ea285b95831e3c73498e4e3ed219ce1d58b079dd962cba3c4c38ea8b6c6448921bfe3f488dd10c19108b7940d7f61d3647f4c0d3a173964 Mageia-Cauldron-netinstall-nonfree-x86_64.iso Hm, that is a different sum than Isodumper report. And it also say so, Sha3, not sha256... Why do IsoDumper not use same sort of sum as the .sha512 files we provide?
(In reply to Morgan Leijström from comment #36) > Hm, that is a different sum than Isodumper report. And it also say so, > Sha3, not sha256... Why do IsoDumper not use same sort of sum as the > .sha512 files we provide? Three checksum files are provided. md5 - an obsolete deprecated md5 checksum provided for use in old versions of other operating systems. sha512 - an obsolete, sha2 checksum provided for use with older systems that do not yet have the sha3 tools. sha3 - The currently recommended checksum method to use. The isodumper checks only the sha3 checksum. Checking the other values would improve the checking should a method be found to hack the file in a way that produces a duplicate sha3 value, but that doesn't at the same time produce duplicate md5 and/or sha2 values, at the expense of additional time taken. As there is currently no known attack like this for sha3, isodumper only checks the sha3 value, not the md5 or sha2 value.
Ah thanks for that explanation. I issued now Bug 28703 - sha3 checksums are missing for our small boot images like netinstaller etc.
Bug 28703 already fixed, and having downloaded both the 8 netinstall nonfree .iso and .sha3 files to same folder and let IsoDumper write it to USB stick it tells: The sha3 sum check is OK but the signature can't be found So it use the sha3 file OK. Are the files to be signed, or it is about to propagate?
Ah, we need the gpg files of course. Reopening 28703 for that.
Advisory ======================== Isodumper reported Incorrect signatures because of the expiration of the locally stored Mageia's key. However, the key wasn't updated. This release check if the key is expired and reload it in this case. Error reporting is also improved. ======================== rpms: isodumper-1.35-1.mga7 isodumper-1.35-1.mga8 isodumper-qt-1.35-1.mga7 isodumper-qt-1.35-1.mga8 isodumper-gtk-1.35-1.mga7 isodumper-gtk-1.35-1.mga8
(In reply to papoteur from comment #22) > The idea of checking the signature at start is pertinent, but need to modify > the logic of the application. I don't want to do this for now because I > prefer that the update comes quickly. The qt versions works for me in mga7 and mga8 64 bit Plasma. I think we should ship this 1.35-1 now, and continue the testing and development in the version with the new dialogue, Bug 27744
Keywords: feedback => validated_backportWhiteboard: MGA7TOO => MGA7TOO, MGA8-64-OK, MGA7-64-OK
(In reply to Morgan Leijström from comment #42) > > The qt versions works for me in mga7 and mga8 64 bit Plasma. > > I think we should ship this 1.35-1 now, and continue the testing and > development in the version with the new dialogue, Bug 27744 Not a backport, rather a good update ;)
Keywords: validated_backport => advisory, validated_updateSource RPM: isodumper-1.35-1.mga8.src.rpm => isodumper-1.33-1.mga8.src.rpm
An update for this issue has been pushed to the Mageia Updates repository. https://advisories.mageia.org/MGAA-2021-0069.html
Resolution: (none) => FIXEDStatus: NEW => RESOLVED
Many thanks for the hard work!