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

Re: Bug #340306: Specification draft for signed debs

On Jun 11, 2012 12:21 "Ansgar Burchardt" <ansgar@debian.org> 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

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


Reply to: