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