Re: Re: Re: Re: Re: package.xml: md5sum attribute of <file />

# jon@php.net / 2003-11-25 11:29:12 -0500: > On Tue, Nov 25, 2003 at 09:18:05AM +0100, Roman Neuhauser wrote: > > > > > 1. what practical benefit does checksumming individual files > > > > provide over whole-package checksums? > > > > > > It allows the Installer to validate each file as its installed, to > > > guard against any archive extraction errors. > > > > So you say there are real world scenarios where the tgz file is > > deemed ok by both gzip(1) and tar(1), but in fact it's corrupt? > > > > > > 2. why do(es) checksum(s) have to reside inside package.xml? > > > > > > That's the only place they can reside in the archive. Otherwise, the > > > Installer would have to query pear.php.net (or similar) to get the > > > checksums (i.e. it makes the archive standalone). > > > > Is fetching the checksum into a separate file a problem? > > (Console_Getopt-1.0.tgz, Console_Getopt-1.0.md5) > > Are you just attempting to play devil's advocate, or is there some > other motivation for this line of questioning? I'm genuinely concerned about a) the waste of resources that is the current scheme and b) the false sense of security it provides. > I'm certainly not wed to the current implementation; I'm just trying > to explain why it was built the way it exists today. Erm, you've failed the goal so far. At least I don't remember you saying why was the choice made for checksumming individual files. The difference between checksumming individual files or the whole package is moot in case of smaller packages (which, admittedly, means most of them), but begins to stick out with beasts like phpDocumentor, which besides being quite large in itself bundles my ma and her kitchen sink, and even compiled Smarty templates. The user is also led to believe that PEAR employs some sort of security/integrity check. I think there's no dispute that the current scheme doesn't protect against malevolently "tweaked" packages, and I don't see any benefit in the installer being able to point its finger at an individual file when reporting a checksum mismatch: the tarball is either ok or it's not. > If you have an alternate implemention, please suggest it. I'm not the > ony who designed the current system, but I agree there may be flaws in > its design, so if there's a better way to do this, let's consider > changing. No implementation (yet), but the idea is this: only package-level checksum, fetched from the server in a separate request, cached on the disk, perhaps with this interface: pear checksum [-r [-s]] checksum check the computed md5 sum against one found in ${pkgfile%.tgz}.md5 (if present) or one returned by pear server checksum -r query server even if the md5 file is present checksum -rs query server even if the md5 file is present, and save the result in ${pkgfile%.tgz}.md5, overwriting any existing file This doesn't really give you any more security than the current scheme, but at least saves some cpu cycles. Of course, it *does* make sense to store a CRC of individual files when they're installed: say if I install Log-1.8.0 and make a tweak to Log/file.php, I won't want to lose my changes in a careless / colleague-performed update. Or something like that (IIRC you use a *BSD so I hope my vague description rings a bell with ports' handling of locally modified files). -- If you cc me or remove the list(s) completely I'll most likely ignore your message. see http://www.eyrie.org./~eagle/faqs/questions.html