Re: Bug #340306: Specification draft for signed debs
On Tue, 2012-06-12 at 08:19:15 +0200, Joerg Jaspert wrote:
> On 12874 March 1977, Niels Thykier wrote:
> > 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).
> Question is - what happens if i put a data.tar.xz behind a sigs.tar.gz
> (and data.tar.gz). Unsigned. Or trojan.tar.xz. Or whatever.
> (Whats dpkg doing then, btw?)
For the current behaviour and accepter members layout this is documented
in deb(5). For optional members (like the possible sigs.tar.gz) this
would depend on either new checks in dpkg itself or in an external
verifier like debsig-verify. (Or I didn't understand your question :)
> We might allow in general to put anything behind, but for the archive
> enable a "nothing allowed" mode, probably in dak. IE if dak sees more
> than it should, reject. And an option in apt too, maybe.
Yes, when specifying this it should be clearly decoupled what conforms
a valid .deb format and what subset dak might want to allow. For
example currently dak only allows a subset of valid .deb packages,
which I can see how it makes sense for it being more strict, but
general purpose tools should deal with the standard format.
regards,
guillem
Reply to: