It makes more sense to beef up security in a multi-modal fashion.
For example, arch's security model already presumes that client machines are secure. Therefore, the use of md5 in core arch is ultimately just a redundant (except on NFS :-) layer of verification of the transports and storage layers. Little would be gained by strengthening the hash function given the kinds of disasters it properly protects against. The problem is the coincidence that just that little redundant circuit breaker in core arch /also/ happens to make arch archives (when used in combination with signing) /vastly/ more secure against malicious attack than /CVS/ servers, not least against the specific kind of attack we've seen take place against an important /CVS/ server. Well, that's great that we trivially win so soundly against /CVS/ in terms of security, but we shouldn't misinterpret that happy result by assuming we therefore have to turn up the security features in core arch as far as they can go. As I've pointed out: just adding new security code creates new risks. Security code has to be /really/ good to do more good than harm. Meanwhile, tighter security is achievable -- sensibly -- in site specific ways: e.g., use a pqm or hair up your signing rules to add new hashes or fancier signing. There's no reason (hence no excuse) to keep churning code in core arch in this area. -t _______________________________________________ Gnu-arch-users mailing list [email protected] http://lists.gnu.org/mailman/listinfo/gnu-arch-users GNU arch home page: http://savannah.gnu.org/projects/gnu-arch/
