Subject: Re: signed binary pkgs
To: Alan Barrett <>
From: Curt Sampson <>
List: tech-security
Date: 07/29/2005 16:22:39
On Tue, 26 Jul 2005, Alan Barrett wrote:

> On Tue, 26 Jul 2005, Curt Sampson wrote:
>>> Yes, I'd like to see a signature on the entire ${package}.tgz file.
>> What are the advantages of this? What are the disadvantages?
> 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.

     Easy to check: no, because you have to go fetch a separate file.
     (Assume that pkg_add will always check the signature if it can
     somehow find it.)

     Can have signatures from third parties: I see no reason not to allow
     multiple signatures on an archive, so that you could re-sign an
     already-signed archive.

>>> I'd also like to see an option to sign a bundle of packages, to reduce
>>> the disk space overhead.
>> It doesn't seem to me that there's going to be so much overhead anyway,
>> and we'd achieve minimal overhead or very close to it in all cases if we
>> put the signature in the archive itself.
> If the signature includes a copy of the key, and perhaps also
> certificates and other metadata associated with the key, then we could
> be talking several kilobytes per signature.  With around 400 syspkgs for
> the base system (not including X11), that's an overhead of a megabyte or
> three.

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,
with signatures, in his keyring, or can fetch it if he needs it. The
only reason to have a copy of the key at all is for use as a checksum of
sorts if the user does not have his own copies of the key.

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

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

> I want it as an option, not as the only way to sign packages.

Oh, but you already do have the option! We could do that right now,
albeit it's a bit of manual work to use and verify.

>  1. Package builder embeds a signature in the package.  The signature
>     means something like "This package really was built in the
>     time/place/manner that the +BUILD_INFO file says."
>  2. A third party adds an additional embedded signature (or replaces an
>     existing embedded signature).  The signature means "This package
>     was approved by the signer (according to criteria specified out of
>     band)."
>     For example, NetBSD release engineering could replace the signature
>     from an automated build process with a signature that means "this
>     package is part of the official NetBSD-x.y.z release", or a
>     corporate QA/security/sysadmin department could add a signature
>     that means "this package is approved for use on company servers".

Both of these sound good to me.

>  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?

>  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

I dunno; the whole idea of #4 just seems to add a lot of complexity for
little gain.

Curt Sampson  <>   +81 90 7737 2974
      Make up enjoying your city life...produced by BIC CAMERA