Marc Haber <[EMAIL PROTECTED]> writes: > On Mon, 01 May 2006 09:30:55 +0200, Florian Weimer <[EMAIL PROTECTED]> > wrote: >>The downside is that anything that doesn't work on entire .debs is >>very likely to change them at the byte stream level (you only need to >>use slightly different zlib versions or parameters). This means that >>the chain of cryptographic hashes that guard against malicious mirror >>or network operators breaks. 8-( > > Since having cryptographic hashes is very very low on the priority > list of the people in Power over Debian, I wouldn't care too much. > > Greetings > Marc
I think what he ment is the md5sum in Packages.gz and apt-get cares about them on download only. If you put the result of patching the debs to a new version directly into apts cache it will eat them even with a wrong checksum. I actualy have a little hack how one could implement patch debs now to test this out: 1. Create an archive mirror with rsync batch files (or xdelta or whatever) between the last and current version of each package. It might be simplest to replace the data.tar.gz in each deb with the rsync batch file and leave the rest of the deb as is. 2. Create Packages.gz and friends for those patch debs 3. Create an apt method "http-patch" to apt that will first check for the old version of the package or dpkg-repack it, then forks the http method to download the patch deb, applies the patch and returns the build deb. 4. Add deb http-patch://server/path suite dist to sources.list _before_ the normal http url. One drawback of this hack would be that you get an error from the http-patch method when you don't have the previous version available before apt-get falls back to the http url. MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]