Re: Add signatures and stronger hashes to deb files (was: Re: [debhelper-devel] Request to re-open "Bug#540215: Introduce dh_checksums" discussion)
- To: Niels Thykier <email@example.com>
- Cc: debhelper <firstname.lastname@example.org>, Wouter Verhelst <email@example.com>, Russell Coker <firstname.lastname@example.org>, Harald Braumann <email@example.com>, Guillem Jover <firstname.lastname@example.org>, Anthony Towns <email@example.com>, Frank Lin PIAT <firstname.lastname@example.org>, Russ Allbery <email@example.com>, Ryan Niebur <firstname.lastname@example.org>, email@example.com, firstname.lastname@example.org, Debian Lintian Maintainers <email@example.com>, Dpkg-Maintainers <firstname.lastname@example.org>
- Subject: Re: Add signatures and stronger hashes to deb files (was: Re: [debhelper-devel] Request to re-open "Bug#540215: Introduce dh_checksums" discussion)
- From: Mimi Zohar <email@example.com>
- Date: Wed, 02 Sep 2015 22:14:04 -0400
- Message-id: <[🔎] firstname.lastname@example.org>
- In-reply-to: <[🔎] 55E72C7B.email@example.com>
- References: <firstname.lastname@example.org> <[🔎] 55E72C7B.email@example.com>
On Wed, 2015-09-02 at 19:06 +0200, Niels Thykier wrote:
> On 2015-07-06 19:11, Mimi Zohar wrote:
> > Hi!
> > When I opened the "Bug#766267: debhelper: add file signature support
> > in .deb packages" feature request for adding file signatures to debian
> > packages, I wasn't aware Franklin Liat submitted a feature request in
> > 2010 for sha256 support - Bug#540215: Introduce dh_checksums.
> > Unfortunately, I only came across the discussion recently.
> > There was a rather long discussion at the time as to whether larger file
> > hashes provide any additional security. Franklin's summary of the
> > discussion is available here:
> > https://lists.debian.org/debian-devel/2010/03/msg00971.html
> > Since that discussion in 2010, the linux-integrity subsystem has matured
> > and can now be configured to verify and enforce local file integrity
> > based on file signatures. I would like to re-open the discussion for
> > including larger file hashes and file signatures in deb packages.
> > Mimi
> > [...]
> Hi Mimi,
> Thanks for following up on this and apologies for my tardiness in
> replying to you.
Perfect timing. I was just about to repost. :)
> If I understand the situation correctly:
> 1) #540215 Rewrites dh_md5sums into dh_checksums
> - Without signing the scripts + ELF files, using a stronger hash is
> largely irrelevant
> - Per #540215 comment #25 (Russ Allbery)
> 2) #766267 includes a script to create postinst scripts to extract
> signatures from shaXXXsums control files and put them on scripts
> and ELF files.
> - And also an alternative dh tool to generate these checksums files
> => This does *not* appear to include a solution for signing these
A sample script named ima-signhashes.sh is included in the samples/
directory. How and when files are signed is an issue that needs to be
> 3) Lintian would need a lot of updating.
> 4) debsums only supports md5sums at the moment.
> - Unconditional removal of md5sums would regrade debsums's
> - dpkg -V has (or intends to) mostly replace debsums
> 5) There is an open policy bug (#572571) documenting package checksums
> - While a related topic, it is not clear to me it is directly
> inspired by this debate.
> 6) AFAICT, we would need kernels with CONFIG_IMA=y (#788290)
> I have had a brief chat with Guillem on if and how dpkg should be
> involved in this. Our chat was based on , which are the
> minutes/notes from an ad-hoc meeting between Guillem and I at DebConf on
> dpkg metadata (and declarative packaging). Items of interest include:
> * Including a manifest of the package.
> - The current idea is to use an mtree-like format to have per-file
> metadata. Either in the control.tar or using the tar "pax" format
> metadata in the data.tar.
> - It would aim to (eventually) replace the md5sums and conffiles in
> the package plus some files in the dpkg database (.list, .md5sums,
> * The mtree-like format can also store extended attributes (key=value
> format) on each file.
> - This could be to include xattrs (incl. IMA signatures).
> Guillem and I hope these items will eventually be handled by tools in
> dpkg and dpkg-dev. However, I am definitely open to prototyping the
> build-side in debhelper if this can speed that change up.
> The above solution would also solve two of my concerns with the proposed
> implementations. Namely,
> * The deployment of the signatures involves adding maintainer scripts
> in all packages (with scripts or ELF binaries).
> - It would undermine our effort to reduce the number maintainer
> scripts (see  for the effort and rationale)
> * The proposed solutions seem to add exactly one new checksum meaning
> that we have to do another "transition" when it is time to deprecate
> "sha256" (or "sha512").
The hash algorithm can be provided to the #766267 checksum version. The
resulting output file name encapsulates the algorithm (eg. sha256sums,
> It does leave at least one item unsolved:
> * How do we get the signatures into the debs while:
> - ensuring the build is non-interactive
> - ensuring the result is reproducible
> - enabling us to add signatures to debs not built by the maintainer.
> => Presumably a post-build mangling will solve this. Anyhow, from
> my point of view, this can come us a separate step.
And the private key used for file signing needs to be protected.
> Proposal for moving forward
> As I see it:
> 1a) Someone volunteers to find a solution getting signatures in the
> - I am willing to help, but I cannot drive this.
> 1b) We work with the dpkg maintainers on the design of new manifest
> - Not sure where we are on this. As mention the current idea is
> to base it on "mtree".
> 2a) dpkg gains support for handling the new manifest file on install
> - In the absence of support, the file will be mostly ignored, so
> this is not a blocker for adding the file to the packages.
> 2b) dpkg or debhelper starts including the new manifest file in
> 2c) lintian gains support for the new manifest file
> - at the very least, it should not complain about its presence.
I'm not sure how much of a help I'd be on the design, but I can at least
> 2d) [optional?] Update debsums
> 3) We update policy (e.g. #572571)
> --- At this point we have stronger checksums ---
> 4) We look at implement 1a) once we have a more concrete
>  https://lists.debian.org/debian-dpkg/2015/08/msg00031.html
>  https://lists.debian.org/debian-devel/2015/08/msg00412.html