Subject: Re: signed binary pkgs [was: Re: BPG call for use cases]
To: Curt Sampson <email@example.com>
From: Steven M. Bellovin <firstname.lastname@example.org>
Date: 07/23/2005 20:58:07
In message <Pine.NEB.email@example.com>, Curt Sampson
>On Fri, 22 Jul 2005, Steven M. Bellovin wrote:
>> If the hash is only being used to identify changed files for
>> pkg_delete, MD5 is fine. For security, you're quite right.
>Ah, I'd not realized the purpose of it.
>> Two issues occur to me. First, what if there are extra files in the
>> archive? The contents list has to be defined to be complete. Second,
>> what about duplicate entries in the archive and contents file? The
>> semantics of that need to be defined and enforced.
>It doesn't seem hard to produce a warning or an error if there are any
>files in the archive not listed in the signature document, outside of
>the signature document itself.
It's not a warning, it's a flat-out error. Think of, say, /root/.profile
or /etc/shosts being in the archive.
>If there are two files with the same name in the archive, the later
>would be extracted over the earlier, anyway. Either they are the same
>file, then, in which case we check twice and both pass, or they are
>different, in which case one will fail the check, which can be treated
>as any other failure.
Will the later be extracted over the earlier? I've seen extraction
programs that refuse to overwrite existing files. Or what if the
verification against the hash is done at extraction time?
>And in the inverse situation, with two entries in the signed file list,
>either they will have the same hash, in which case it's irrelevant, or
>they will have different hashes (for the same hash scheme), in which
>case one will fail.
>Assuming one defines the check algorithm to check every hash in the
>list, and produce an error if there are any files that were not checked,
>what are the weaknesses in this scheme versus just signing the entire
>archive as a whole, I wonder?
It's as strong *if* you've defined all the cases properly. The
examples I've given are places where a straight-forward approach just
doesn't cut it; it's not well-enough defined.
--Steven M. Bellovin, http://www.cs.columbia.edu/~smb