FS#28014 - Corrupted Package Handling in pacman using PGP Signing
Attached to Project:
Pacman
Opened by Chad Shets (cvillelk) - Friday, 20 January 2012, 15:28 GMT
Last edited by Allan McRae (Allan) - Tuesday, 15 October 2013, 02:49 GMT
Opened by Chad Shets (cvillelk) - Friday, 20 January 2012, 15:28 GMT
Last edited by Allan McRae (Allan) - Tuesday, 15 October 2013, 02:49 GMT
|
Details
Description:
pacman 4 makes no distinction between a signing issue and a transmission corruption issue. A post-download checksum applied to the signed package would be one remedy. - - - - - - - - - - - - - - - - - - When a package being handled by pacman 4 fails the PGP sig check an error similar to the following is reported: | error: libreoffice-common: signature from "Andreas Radke <andyrtr@archlinux.org>" is invalid | error: failed to commit transaction (invalid or corrupted package (PGP signature)) | Errors occurred, no packages were upgraded. This is less intuitive and helpful than the old checksum method ( < pacman 4; shown below after a transmission corruption). | :: File /var/cache/pacman/pkg/libreoffice-common-3.4.5-1-x86_64.pkg.tar.xz is corrupted (invalid or corrupted package (checksum)). | Do you want to delete it? [Y/n] y | error: failed to commit transaction (invalid or corrupted package (checksum)) | Errors occurred, no packages were upgraded. The prompt offers to delete the corrupted file, which makes re-downloading the package easier (otherwise the user must manually delete the corrupted package). In it's current form, It is not readily apparent whether a PGP signing error occurred or a file corruption. I, for example, thought my PGP signing was incorrectly setup which had me scanning forums for a while. Mentioned in the forum here: https://bbs.archlinux.org/viewtopic.php?id=133938 Additional info: Pacman 4.0.1 Steps to reproduce: To recieve the checksum message, I changed SigLevel = Optional TrustAll to SigLevel = Never |
This task depends upon
Closed by Allan McRae (Allan)
Tuesday, 15 October 2013, 02:49 GMT
Reason for closing: Fixed
Additional comments about closing: commits 0d89c10f and ed511b14
Tuesday, 15 October 2013, 02:49 GMT
Reason for closing: Fixed
Additional comments about closing: commits 0d89c10f and ed511b14
Comment by Dan McGee (toofishes) -
Saturday, 11 February 2012, 21:57 GMT
Comment by
Kerrick Staley (KerrickStaley) -
Monday, 22 October 2012, 06:11 GMT
Comment by Allan McRae (Allan) -
Saturday, 09 February 2013, 02:51 GMT
Comment by
Jorge Villaseñor (salinasv) -
Saturday, 20 April 2013, 02:32 GMT
Comment by Allan McRae (Allan) -
Saturday, 20 April 2013, 03:18 GMT
Comment by
Jorge Villaseñor (salinasv) -
Wednesday, 24 April 2013, 04:06 GMT
Comment by
Jorge Villaseñor (salinasv) -
Monday, 06 May 2013, 04:13 GMT
Comment by Allan McRae (Allan) -
Tuesday, 15 October 2013, 02:49 GMT
- Field changed: Status (Unconfirmed → Assigned)
- Field changed: Category (Packages: Core → Backend/Core)
- Field changed: Reported Version ( → 4.0.1)
- Field changed: Due in Version (Undecided → 4.0.3)
- Field changed: Architecture (All → All)
- Task assigned to Dan McGee (toofishes)
I think I agree here- we can probably run multiple checks if the
first one fails, that way you get more feedback on what is
potentially wrong.
It should be enough to just emulate the old behavior--if the
package doesn't pass the PGP check, offer to delete it. If the
problem persists, the user will know that their PGP configuration
is at fault, rather than it being a one-off issue with the
download.
This is half implemented in commit 0d89c10f which offers to delete
the package if signature checking fails. It would still be better
to check the checksum after failing signature to more easily allow
the user to determine the source of the error.
It would be nice if the error shows the name of the package not
passing the integrity check.
With pacman-4.1 it should be offering to delete the corrupt
package - so that requires showing its name... Is that not
happening?
Yep, it happens with 4.1.0
My bad, I have just seen the message and it says which package is
corrupted. Maybe I saw the problem with previous version of pacman
and it got updated in that -Syu.
And commit ed511b14 should close this bug.