On Fri, 29 Jul 2005, Curt Sampson wrote:
> On Tue, 26 Jul 2005, Alan Barrett wrote:
> [re: signature on the entire ${package}.tgz file]
> >Advantage: easy to generate; easy to check; can have signatures from third
> >	parties.
> 
> Let's deal with these one at a time:
> 
>     Easy to generate: we can make internal signatures just as easy to
>     generate, if we write the tool correctly.

I meant "easy to write the tool".

> First of all, I'd suggest not including signatures on the key; anybody
> who's got any level of trust in the key will have his own trusted copy,

OK.  That saves some overhead.

> And even so, a megabyte or three on 400 packages? What percentage of the
> space is that?

1 to 2 percent.  This might not sound like a lot to you, but when I am
trying to fit a full release plus as many useful packages as possible
onto a single CD-ROM, every little bit helps.

> And besides, if you wanted to use one signature across a bunch of files,
> why would you not just put them together in an archive and sign the
> archive?

I might not want to install all the files, so I can save space and
bandwidth by fetching only the files I want.  It's also easier (and uses
less temporary disk space) to install a single package if it's in it's
own file, rather than having to extract it from an archive first.

> > 3. A third party creates a detached signature on a single package.
> 
> This we already have, albeit without automatic verification of a
> detached signature. How do you feel about not having the automatic
> verification, but continuing with current mechanisms?

I find the existing "pkg_add -s" much too inflexible.  There's no way at
present to tell it to call a script of my choice with args giving the
package name and other relevant details.

> > 4. A third party creates a detached signature on a bundle of
> >    packages.
> 
> Is putting the packages in an archive and signing the archive a suitable
> solution? If not, can the signature verify some packages if not all are
> present?
> 
> I dunno; the whole idea of #4 just seems to add a lot of complexity for
> little gain.

It seems very easy to me.  The signer does something like this:

	for package in ${list} ; do
	     checksum ${package}
	done >${checksumfile}
	sign ${checksumfile}

The hypothetical "checksum" command outputs stuff like

	Size (foo-1.2.3.tgz) = 4567 bytes
	SHA1 (foo-1.2.3.tgz) = da39a3ee5e6b4b0d3255bfef95601890afd80709

so the detached signature breaks if somebody modifies the embedded
signature, but that seems like a reasonable tradeoff to me.

The installer fetches a copy of the signed checksumfile, and fetches
copies of as many or as few packages as they like; then they verify
the signature on the checksumfile, and use the checksums to verify the
packages.  To make it easy for the installer, "pkg_add -s" should be
taught how to search for the right lines in the checksumfile.

--apb (Alan Barrett)