Re: Requirements of the tool (dpkg) support for signed packages
>
> A signature attached to a .deb should be a separate member in the `ar'
> archive that is a .deb. It should be the last thing in the .deb and
> should cover everything except itself. Probably the signature should
> be in PGP/GPG format.
>
In my implementation it is a seperate member named something like
"_data.sig". The prepended "_" insures that older dpkg's will simply ignore
this member, and yes it does come after all other members.
> It _shouldn't_ just be a signature of the control.tar.gz or
> data.tar.gz or some other strangely-computed subsection in case we add
> other new members.
In my current implementation, the sig is of the uncompressed data.tar.gz
(i.e. data.tar) and control.tar.gz files. This is for very specific reasons,
one of which is so that the internal compression can be changed (to .bz2 for
example) without breaking the signature. Why shouldn't each member be signed
seperately? How would you propose we sign the entire pacakge, *and* include
the sig in it? Plus doing it your way would mean that the compression could
not be changed without destroying the signature validity.
> It would be nice if the signature for a signed Packages or md5sums or
> whatever could be attached to the file to prevent mirror skew from
> making the signature (and thus the file) unuseable. However, that
> would mean at least putting them in PGP ASCII armour format, which
> would not be completely backwards-compatible.
In the above case as I explained, it is attached in the .deb, and is
completely backwards compatible with older dpkg versions. Also, ASCII armour
is much larger than binary sigs. I think we should keep the footprint of
this small on the package end, and use binary.
> * Algorithm
>
> We should use RSA and SHA-1. We're not going to deploy this before
> September anyway so the RSA patent isn't a problem. RSA is simpler
> (less code in the checking stage) and also doesn't leak your key like
> DSA does if you make a signature using a bad (or compromised) RNG.
Beyond the scope of my knowledge, so I'll trust your jusdgement. IMO, we
should simply use the tools we have available, which is pgp and gpg, and not
write all new cyrpto/signature programs for this.
> 3. Protocol structure representation
>
> We don't want to encode too much policy and protocol in the code. I
> think we should use SPKI/SDSI.
Eh?
--
-----------=======-=-======-=========-----------=====------------=-=------
/ Ben Collins -- ...on that fantastic voyage... -- Debian GNU/Linux \
` bcollins@debian.org -- bcollins@openldap.org -- bmc@visi.net '
`---=========------=======-------------=-=-----=-===-======-------=--=---'
Reply to: