FS#5120 - pacman: silently installs partially downloaded packages

Attached to Project: Pacman
Opened by Alexander Baldeck (kth5) - Thursday, 27 July 2006, 08:36 GMT
Last edited by Aaron Griffin (phrakture) - Monday, 22 January 2007, 16:17 GMT
Task Type Bug Report
Category
Status Closed
Assigned To Aaron Griffin (phrakture)
Architecture not specified
Severity Medium
Priority Normal
Reported Version 0.7.2 Gimmick
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 0
Private No

Details

i just downloaded kdenetwork 3.5.4 made by tpowa, i installed it without realizing the download was incomplete. pacman didn't complain at all and actually installed the broken package.

is it possible to move the meta data to the end of the tarball so that if it's not completely downloaded is not recognized as a valid package? probably pretty simple, no?

=================================================================================

[maetrik] 3.5.4 $ sudo pacman -U kdegraphics-3.5.4-1.pkg.tar.gz
loading package data... done.
checking for file conflicts... done.
upgrading kdegraphics...
could not extract opt/kde/lib/libkpovmodeler.so.0.0.0: Invalid argument
errors occurred while upgrading kdegraphics
done.
/sbin/ldconfig: file /opt/kde/lib/libkpovmodeler.so.0.0.0 is truncated


[maetrik] 3.5.4 $ pacman -Qi kdenetwork
Name : kdenetwork
Version : 3.5.4-1
Groups : kde
Packager : Tobias Powalowski <tpowa@archlinux.org>
URL : http://www.kde.org
License : None
Architecture : i686
Size : 28816695
Build Date : Tue Jul 25 15:43:37 2006 UTC
Install Date : Thu Jul 27 08:32:05 2006 UTC
Install Script : No
Reason: : explicitly installed
Provides : None
Depends On : gnutls>=1.2.4 kdebase>=3.5.4 kdelibs>=3.5.4 libxss openslp perl-io-socket-ssl ppp qca-tls rdesktop wireless_tools
Required By : None
Conflicts With : None
Description : KDE Networking Programs.
This task depends upon

This task blocks these from closing
 FS#6316 - Pacman 3 release bugcatcher 
Closed by  Aaron Griffin (phrakture)
Sunday, 04 February 2007, 03:43 GMT
Reason for closing:  Fixed
Additional comments about closing:  libalpm now fully verifies all archives
Comment by Jan de Groot (JGC) - Thursday, 27 July 2006, 09:05 GMT
pacman -U installs every package you feed it. You could even feed it a tarball which is not a package, but it will complain there's no PKGINFO or FILELIST file in it. The question here is: do you really want to add this type of complexity to pacman? Do we need to check if all the files in a filelist are also installed? I guess this would make pacman even slower than it is already.
Comment by Alexander Baldeck (kth5) - Thursday, 27 July 2006, 09:20 GMT
the thing is just that this way broken packages get installed and since pacman already checks for the meta data including values for filesize and stuff, why not use them?
Comment by Simo Leone (neotuli) - Thursday, 27 July 2006, 15:32 GMT
if you were installing from a real repo, pacman would have complained about a corrupt package, since it keeps md5sums in with the database. The reason we have the metadata first is so that it's a bit faster to read. I don't know how costly a tar tzf type of operation is, but maybe comparing that against the file list metadata would be a semi-reasonable (and not so expensive) way to at least make sure all the files are there. Though that obviously doesn't guard against partial files and corruption and such, it might be better than nothing.
Comment by Aaron Griffin (phrakture) - Monday, 22 January 2007, 16:17 GMT
pacman 3 currently fails if a .PKGINFO file is not present. I'm trying to think why this doesn't include .FILELIST as I can't forsee a when this wouldn't be present... I just added FILELIST for completeness.

edit: whoops, it seems I misunderstood the initial bug report. Let me think on this.
Comment by Aaron Griffin (phrakture) - Sunday, 04 February 2007, 02:08 GMT
Ok, after re-looking at this, I'm fairly confused. If a gzip file is corrupt, shouldn't the gunzipping algorithm/whatever KNOW that? How does it even begin to extract itself, if it's corrupt? I don't know compression algorithms that well, but I thought there was some sort of check for this?

Can someone give me a solution for this, I can't really think of anything.
Comment by Aaron Griffin (phrakture) - Sunday, 04 February 2007, 03:11 GMT
Ok, looks like this can be handled by running through the archive once before hand (libarchive will return the proper errors). Since libalpm already does this for package metadata, we can simply remove the "early return" when all metadata is found to verify archive integrity.

Should be fixed in CVS momentarily, and a new pacman RC will be released soon.

Loading...