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

[Mimi Zohar]

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

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

>  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").

The hash algorithm can be provided to the #766267 checksum version.  The
resulting output file name encapsulates the algorithm (eg. sha256sums,
sha512sums).

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

I'm not sure how much of a help I'd be on the design, but I can at least
do this.

Mimi

>  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