Re: Signing Packages.gz
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
Reply to: