Re: Bug #340306: Specification draft for signed debs
On 12874 March 1977, Niels Thykier wrote:
>> 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?
Not by us, or shouldn't. But for some suites, like the p-u one, we
publish the .changes too, so people CAN use them for importing
somewhere.
Not sure its a valid reason to let it go.
Actually, I would like to have them signed by dak too, yes.
> 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).
The sigs tarball wont be signed ever, so we can put new sigs in as much
as we want.
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?)
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.
--
bye, Joerg
[...] could be redistributed free (as in "free bear") [...]
Reply to: