On Sat, 1 Apr 2000, Marcus Brinkmann wrote: > In the signed .debs case, I, as a developer, assert that the package comes > from me. A user can directly verify this by checking the signature.
No, the user cannot verify that. The user can check the signature against our keyring but they have no idea who *should* have signed it. This means that all I need to do is nix one of our maintainers keys and I can undetectably forge Debian packages willy nilly. This is aside from the other problem of keeping 600 keys up to date on the client machines and making sure that huge keyring is not disturbed in transit. > whatever comes from dinstall, but he can not directly check if what is in > the archive comes really from the developers (not a problem if dinstall can > be trusted). If we store the .changes files as I propose then the end use can check it, if they want. But nobody will, because it is not a usefull thing to check. It has use to definitively verify the root archive (say, after a hacking or something) but otherwise the end user cannot make much use of it at all. > The latter adds a chain, thus one further point of weakness. I might add > that as the dinstall key can't be kept truly secret if it is stored on a > net-connected machine, this weakness is rather huge. The dinstall and security keys (particularly the security key) are going to be far, far more secure than the weekest key in the key ring. > I could not trust either. The former, because it is stored on a network > connected machine, the latter because it is transfered over the net (if it This is a flawed assertion - by your logic SSL is insecure and must not be used. In reality it is a perfectly good system that has really good security benifits. Jason