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. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org