Currently, with the key expired, isodumper reports in the dialog ... "The validation of the GPG signature of the checksum file failed ! Do you want to continue?" (without the double quotes), and then in the text log "Mageia key expired, reloading Signature is false" An expired key is not a revoked key. A signature that was valid the day before the key expired is still a valid signature. The gpg command produces ... "gpg: Good signature from "Mageia Release <release@mageia.org>" [expired] gpg: Note: This key has expired!" The information message from gpg is correct. It is not a false signature.
Just to clarify: - A revoked key can not be used. Any signatures previously created by it's private key can no longer be trusted. - An expired private key can not be used to generate new signatures (without extending it's expiry date to be past the present date). An expired public key can still be used to validate signatures created before it expired. - A good signature tells you the signature was made by someone in possession of the private key and it's passphrase, that the key was valid when the signature was generated, and that the file has not changed since the signature was generated. - If you encounter a good signature created after the public key has expired, then an updated copy of the public key should be obtained. It's up the the user whether to actually get the updated key, checking for a revoked key in the process, or to choose to trust the good signature.
Assigning to papoteur!
Assignee: geiger.david68210 => yvesbrungard
CC: (none) => fri
(In reply to Dave Hodgins from comment #1) > - An expired private key can not be used to generate new signatures (without > extending it's expiry date to be past the present date). An expired public > key can still be used to validate signatures created before it expired. > > - If you encounter a good signature created after the public key has expired, > then an updated copy of the public key should be obtained. It's up the the > user whether to actually get the updated key, checking for a revoked key in > the process, or to choose to trust the good signature. How to know the date at which the signature has been done? I could use the date of the signature file, but this is not secure. I could use the file DATE.txt, but this file is not signed nor in checksum, thus not secure too. I don't have secured means to say that the signature has been done before or after the expiration date. Thus the information in case of expiration at today date is to say : this signature can not be trusted. @Dave: Do you agree?
The date is included in the contents of the signature, and shown in the gpg output. For example ... $ gpg --verify Mageia-9-Live-Xfce-i586.iso.md5.gpg gpg: Signature made 2023-08-24T17:26:08 EDT gpg: using RSA key B21076A0CBE4D93D66A9D08D835E41F4EDCA7A90 gpg: Good signature from "Mageia Release <release@mageia.org>" [expired] gpg: Note: This key has expired! Primary key fingerprint: B210 76A0 CBE4 D93D 66A9 D08D 835E 41F4 EDCA 7A90 The person generating the signature can create a signature with an incorrect date by altering the time in their computer, but the date cannot be forged by others unless the entire signature can be too, in which case either the secret key has been obtained by an attacker or the signature algorithm used by gpg has been broken.
(In reply to papoteur from comment #3) <snip> > Thus the information in case of expiration at today date is to say : this > signature can not be trusted. > @Dave: Do you agree? Sorry, missed this part. I do not agree. The signature can be trusted. It detail ... If gpg --verify reports a "Good signature", then the signature can be trusted to have been created by a person in possession of the key and it's pass phrase before the key may have expired, and that the file that was signed has not been changed. From https://www.rfc-editor.org/rfc/rfc4880#page-70, the signature packet contains the creation date/time, key ID of the signer, the algorithms used, and the hash value. All of the contents of the signature packet are encrypted using the secret key. Validating a signature decrypts the signature packet using the public key, and then compares the hash to the hash calculated from the signed file. As the creation date of the signature has been obtained by decrypting the signature file, rather then from the file system, the date can be trusted.
Thanks Dave, I found the way to check that, now. Should we report that "Note: This key has expired!"?
It may be too easy to upset users. I would like a more explaining form: "The date of the key have expired, but it is still valid for checking the ISO." Comparison: The real danger instead lies in using the ISO:s without updating the system after install due to security issues with old browsers etc, and isodumper do not tell users that (And I do not think it should)
I'd change the msg to "Info: Key has expired. Updated version may be available." Just for your info: If they then retrieve an updated version of the key, that is also how they would find out that the key has been revoked, if that is the case. I wouldn't bother trying to explain that in the message.
(In reply to Morgan Leijström from comment #7) > It may be too easy to upset users. > I would like a more explaining form: "The date of the key have expired, but > it is still valid for checking the ISO." I think adding "Info: " at the start of the message to make it clear it's just an informational message, not a warning or an error, is enough. > Comparison: The real danger instead lies in using the ISO:s without > updating the system after install due to security issues with old browsers > etc, and isodumper do not tell users that (And I do not think it should) Agreed. Teaching basic security concepts is not the role of the tool.
commit f403818617909990640d20dcef7123c0a66f16d0 Author: Papoteur <papoteur@...> Date: Tue Oct 1 08:28:46 2024 +0200 Refactor signature checking. - expiration of the key is not an error, just an info (mga#33562) --- Commit Link: https://gitweb.mageia.org/software/isodumper/commit/?id=f403818617909990640d20dcef7123c0a66f16d0
Hello, 1.56 release is coming in Cauldron.
Please build for mga9 too and set bug to QA.
Submitted: SRPMS: isodumper-1.56-1.mga9 RPMS: isodumper-qt-1.56-1.mga9.noarch.rpm isodumper-gtk-1.56-1.mga9.noarch.rpm isodumper-1.56-1.mga9.noarch.rpm
Assignee: yvesbrungard => qa-bugs
From /var/log/magiback.log from before installing this update ... 2024-09-14 14:51:57,256 WARNING Mageia key expired, reloading 2024-09-14 14:51:57,896 WARNING Signature is false 2024-09-14 14:53:09,802 INFO ISO Image to copy: /s3/m9/Mageia-9-Live-Xfce-i586/Mageia-9-Live-Xfce-i586.iso After this update has been installed ... 2024-10-01 11:30:17,015 INFO The checksum file is signed 2024-10-01 11:30:17,016 INFO Info: Key used for the signature has expired. Updated version may be available. 2024-10-01 11:30:17,017 INFO ISO Image to copy: /s3/m9/Mageia-9-Live-Plasma-x86_64/Mageia-9-Live-Plasma-x86_64.iso Validating the update. Advisory added to svn as ... subject: Updated isodumper packages fix expired key message src: 9: core: - isodumper-1.56-1.mga9 description: | Corrects showing expired key message to be an info message, not a warning or error. references: - https://bugs.mageia.org/show_bug.cgi?id=33562
Whiteboard: (none) => MGA9-64-OKCC: (none) => sysadmin-bugsKeywords: (none) => advisory, validated_update
An update for this issue has been pushed to the Mageia Updates repository. https://advisories.mageia.org/MGAA-2024-0205.html
Resolution: (none) => FIXEDStatus: NEW => RESOLVED