Add signatures and stronger hashes to deb files (was: Re: [debhelper-devel] Request to re-open "Bug#540215: Introduce dh_checksums" discussion)

Wed Sep 2 17:06:03 UTC 2015

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.

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
      files.

 3) Lintian would need a lot of updating.

 4) debsums only supports md5sums at the moment.
    - Unconditional removal of md5sums would regrade debsums's
      usefulness
    - 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 [1], 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,
     etc.)

 * 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 [2] 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").

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.

Proposal for moving forward
===========================
As I see it:

 1a) Someone volunteers to find a solution getting signatures in the
     debs.
     - I am willing to help, but I cannot drive this.

 1b) We work with the dpkg maintainers on the design of new manifest
     format.
     - 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
     packages

 2c) lintian gains support for the new manifest file
     - at the very least, it should not complain about its presence.

 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
    solution.

Thanks,
~Niels

[1] https://lists.debian.org/debian-dpkg/2015/08/msg00031.html

[2] https://lists.debian.org/debian-devel/2015/08/msg00412.html

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <http://lists.alioth.debian.org/pipermail/pkg-perl-maintainers/attachments/20150902/dacaa73b/attachment-0001.sig>