Jordan Brown wrote: > Indeed. The question is whether breaking the assumption that two > installations of the same version of a package will have bit-for-bit > identical files is acceptable. I'd personally say "no", that it's a > reasonable and valuable assumption and that breaking it is likely to > cost more than any savings. (Remember that service calls start at about > $25 each just to say "hello", and you can move an awful lot of bits > for $25.)
As much as I like the idea that pkg will only pull down an ELF binary if its executable content has changed I share the same concerns as Jordan. The bart(1) tool and many 3rd party equivalents such as using md5sum or tripwire all look at whole files. Why ? because all files can be dealt with as whole files. Comparing this to what elfsign(1) does for non crypto framework plugins elfsign(1) acts very similar to what pkg(5) does, it only looks at the executable content. For crypto framework plugins I made it looks at the whole file, the reason for this is largely historical and it could be changed (but involves doing real paperwork with the US government for Solaris 10). Consider that end users/admins can use elfsign(1) to sign their own files. This will be come more interesting as parts of the valex[1] OpenSolaris project deliver. Files can actually have multiple signatures and resigning a binary may change what valex policy is applied to it so the signature section needs to be taken into account even though it doesn't directly impact program/library execution. > If you really must optimize out the "unimportant" changes, I'd recommend > pushing it as far "upstream" as possible, to minimize the number of > people who see two packages with different files in them. The stuff I'm > saying about comparing systems isn't a thought experiment; people do > that kind of thing all the time. I agree on this. The population of the repository seems like the place to do this, if at all. I'd be very interested to see some figures, real or projected, on what the bandwith and disk space saving from only updating if ELF executable content is changed. Particularly given that there will be cases where some of the non executable content is the only change to what is in the repository. The resulting "special case" work seems like it might invalidate the benefit in the default case. I'm not dissing the idea, I think it is cool, but I'd like to know how much it saves given the confusion that will result from it. It could cost more explaining why two images are the same. For example I recently had to explain to several very large and important financial sector customers why the crypt_bsdmd5(5) crypt(3C) plugin was still safe even though "the sky is falling" for MD5. The technical people understood the cryptography argument I presented, but the said they couldn't explain that to their operations people or their senior management. The result was that crypt_sha256(5) was born (thanks to a consortium of Red Hat, Sun, IBM, HP): it was in the long run cheaper to not have to explain why it is okay. [1] http://opensolaris.org/os/project/valex/ -- Darren J Moffat _______________________________________________ pkg-discuss mailing list [email protected] http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
