Re: please, let's *completely* drop md5sums for buster (was Re: no-strong-digests-in-dsc MBF)
On Sun, 2017-01-22 at 13:54:26 +0100, Philipp Kern wrote:
> On 22.01.2017 12:34, Bernd Zeimetz wrote:
> > afaik people are criticizing that there are still (only) md5sum files in
> > /var/lib/dpkg/info. As dpkg --verify uses them, it might indeed make
> > sense to replace them.
> > (yes, dpkg is not an IDS, but better than nothing...).
> Originally the thread was about hashes in .dscs, but okay.
Even that part of the thread seems rather confused.
There are digests in the .dsc and .changes files, which get propagated
(perhaps in a filtered way) into Sources and Packages indices, also
(In)Releases files, there are also digests in any of their OpenPGP
signatures. And then there are digests in the .deb control member or
they get generated at install time if missing. And dpkg uses digests
as part of the "public interface" when dealing with conffiles.
When this has come up in the past, I've also always mentioned that
having more digests even if some are considered weak now, does not
make it weaker, it makes it stronger.
The current apt approach seems the best one to me. To consider valid
weak digests necessary but not sufficient. So all digests present need
to verify as valid, but having only weak digests is not enough to
consider the file verifyable.
Removing weak digests from things that do support multiple digests,
just because they are weak, seems to be cargo-culted security. And
ending up with just a single strong digest due to this would be bad.
Removing them because we've got too many, for space concerns is
another thing entirely though.
And if we want to make sure nothing relies on those, then we should
either hunt stuff down via codesearch, or just upload a package with
the set of weak checksums removed, or perform similar tests.
So from the above list of files, the priority IMO should be .dsc with
only weak digests, and any file with weak digests in their OpenPGP
> What exactly
> does that help given that the md5sums can just be modified locally?
Yeah, it makes no sense whatsoever to consider the dpkg md5sums files
some kind of security measure.
> Right now we don't keep the file size in dpkg's database. We keep
> md5sums in an easily modifyable place. We don't easily allow people to
> download just the md5sums information that you'd need to independently
> verify the files on the system.
> We could of course start by providing another hash type, but given the
> purpose for why we have md5sums for installed files in the first place
> (detecting file corruption and modification of files vs. what has been
> installed by the package manager) a different hash type is not going to
Exactly. Also one of my concerns has been that adding stronger
digests might confuse people even more into thinking that this is some
kind of security measure.
> Sure, we could assume for a moment that the attacker could not tamper
> with the md5sums because the admin implemented an elaborate
> SELinux-based scheme that denies modification of the md5sum files on
> disk except when dpkg is invoked. In this case having also the size or a
> combination of hashes would make me more comfortable.
TBH, I'm not sure who in their right mind would trust a running system
to do forensics within itself, if there's suspicion of a security
breach, no matter what security measures it has in place. At this point
in time, you might not even be able to trust the firmware anymore…
> Anyway, that said, is there a bug on this on the dpkg side already?
There are probably some bugs about this, but in any case some of it is
and has been in the plans for some time. It is slowly coming to be.
There's a dpkg-gendigests branch with such new command, but that might
just get replaced with the file manifest generator, which should include
all file metadata, in addition to one or more file digests. There is
also interest and some patches for file signatures which is probably a
way better approach to security than any fantasy based on just the file
digests. So no need for more bug reports, really.