On Jun 11, 2012 12:21 "Ansgar Burchardt" <[email protected]> wrote: > Hi, > > On 06/11/2012 11:26 AM, Niels Thykier wrote: > > Archive support > > --------------- > > > > 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. > > Do you want dak to eventually sign the packages? Note that this would > make them no longer match the hashes from the .changes. >
I think it would be a nice feature to have, as people could then verify that the deb has once been in the Debian archive (without having to look it up on snapshot.d.o etc). I would assume it would be signed by dak after the package has been accepted into archive. Are .changes files still used after that point? > Why is signatures.tar.gz too long? Is that a limitation of the ar > format? > According to ar(1), it depends on the "implementation" of ar. """ GNU ar can maintain archives whose members have names of any length; [...] If it exists, the limit is often 15 characters (typical of formats related to a.out) or 16 characters (typical of formats related to coff). """ To be honest, I am not sure if deb is subject to these limits, but I assumed it was better to err on the side of backwards compatibility here (deb(5) does not seem to document a limit or lack thereof). In particular, debsig-verify currently assumes ar members to be at most 15 characters... though that may a flawed assumption in debsign-verify. > > deb format changes > > ------------------ > > > > deb files can optionally have a member called "sigs.tar.gz" used for > > verifying the authenticity and integrity of contents of the deb > > file. > > The member should be the last, but may appear anytime after the > > data.tar member. > > Implementations should (still) ignore any member after the > > data.tar > > member except for the "sigs.tar.gz" if it is present. > > > > The "sigs.tar.gz" may be used to sign any member preceeding it in > > the > > deb file. Implementations are not required to check for signatures > > for any member occuring after the "sigs.tar.gz". > > Do you plan to support partially-signed packages where only some > members > are signed? I would suggest to treat such packages as having an > invalid > signature as it is likely you will have bugs otherwise (where tools > treat unsigned members after the sigs.tar.gz as signed). > > Ansgar > > The main reason for allowing unsigned members after the sigs.tar.gz was that I read deb(5): """ Current implementations should ignore any additional members after data.tar """ As a "you can always safely stuff a new member in the back"... I probably misunderstood that and if so, I see no problem in considering members after "sigs.tar.gz" as unsigned. However, I do believe that it should be allowed for a member to be signed by a subset of the signers. For example, if someone uploads a signed deb to the archive, then it would still be possible for the archive software to embed a new member (if it signs the new member). ~Niels -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected] Archive: http://lists.debian.org/[email protected]
