[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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


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