Re: Bug #340306: Specification draft for signed debs
On 12874 March 1977, Niels Thykier wrote:
> The FTP masters have requested that all signatures are stored in a
> single ar member of the deb. That "member should then contain a flat
> directory (ie no sub-directories) of signature files, [...]"
> (#340306#33).
> They suggested that the member should be named "signatures.tar.gz"
> (or so), but as it exceeds the name limits I will use "sigs.tar.gz"
> for now.
Yep. And I stand by this as I haven't seen a good reason against it. :)
Also, make it "sigs.tar" plus the compression that the rest of the .deb
members use? dpkg and tools have to deal with a number of them anyways,
so we can make this open too, no need to limit to just one.
> * Checksums-<algorithm> (required, multiline). Contains the
> checksums and sizes of files covered by this signature file.
> - Implementations are required to know/use "Md5", "Sha1" and
> "Sha256".
MD5? Seriously?
Also, make it not too hard to switch those in the future.
> - "vendor": The signer is a vendor (re-)distributing the
> package. The name of the vendor will be in the Vendor
> field. This role can be used in any number of signature
> files (assuming the vendors import the deb "as-is" and
> simply resign it).
So dak would be signing as a vendor, "Debian" or "Debian Archive" (and
probably "Debian Security" and "Debian Backports")?
> Open question: should we allow implementation specific fields with the
> usual "X-<field>" notation (or something similar)?
Yes.
> I also wonder if we should permit signatures to sign other signatures.
> As an example, "When I signed this deb, there was also a signature
> from Alice (who signed it as role X)".
Or a sponsor can say "Yeah, that maintainer signed too".
Might make sense.
--
bye, Joerg
Lisa, honey, if it’ll make you feel better I’ll destroy something Bart loves.
Reply to: