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
