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

Re: Bug #340306: Specification draft for signed debs


On Mon, 2012-06-11 at 11:26:19 +0200, Niels Thykier wrote:
> I would like to help with reviving the idea of "signed deb".  I
> noticed dpkg-sig/debsig-verify is on the dpkg maintainer's "RoadMap"
> [DRM], hench the CC.  I also found [OSPEC], which may be of interest
> or possible the "old spec".
>   I think that we should start with creating "signatures support
> inside .deb"-spec.  I have come up with an initial draft based on my
> observations of dpkg-sig and debsig-verifiy below.  Feel free to
> review and suggest ammends to it.

Thanks for digging into this! I've skimmed over the draft, and will be
replying to some minor specific issues that have been brought up in the
thread, but I'll only be seriously participating and pondering about all
this once the freeze is started, so I guess in few weeks, because I'd
like to focus on finishing some other dpkg stuff first.

> Once we have created the specification, I suggest we use dpkg-sig (and
> possibly debsig-verify) to create a prototype implementation of it and
> get archive support for it.

JFYI (in case people don't remember / are not aware) dpkg supports
using the debsig-verify interface, but it's disabled by default in

> signature files
> ---------------

> Open question: should we allow implementation specific fields with the
> usual "X-<field>" notation (or something similar)?

Using X- to extend fields has been controversial in the past for
dpkg control files, we discussed this some time ago (IIRC in
debian-policy), and for 3rd parties I added Private- as a prefix that
would not trigger warnings from dpkg-deb. I've just noticed this is
not documented in the man page, will quickly fix that.

> Remarks
> -------
> [OSPEC] also includes a section of how to create policies to verify
> these deb signatures.  I do believe a standardized "verfication policy
> framework" is a commendable thing, but I also believe it written on
> top of this specification later.

Sure, I'd appreciate if that would not rely on stuff like an XML parser,
though. :)


Reply to: