Re: [PATCH] libdpkg: Use OpenSSL for hashing.
On 2023-07-01 13:16:17 [+0200], Guillem Jover wrote:
> Hi!
Hi Guillem,
> On Sat, 2023-07-01 at 00:03:53 +0200, Sebastian Andrzej Siewior wrote:
> > Would it be acceptable to to switch it?
>
> I gave the reasoning for switching from the embedded MD5
> implementation to libmd at
> <https://lists.debian.org/debian-devel/2022/07/msg00045.html>, and I
> think it still holds. (This would also imply pulling OpenSSL or any
> other crypto library into the current essential-set, which are not
> small compared to the minimal libmd library.)
I can't comment on that. libssl is pretty much part of every
installation. libgcrypt is part of every debootstrap due to gpg.
The essential-set seems to be something different and looking at libmd's
size of 60KiB vs libssl 6MiB it is hard to argue for libssl :)
As I said, can't comment on that but thanks for the background.
> Right, this is not for security reasons, but for integrity ones. This
> part of the interface (debsums assume these exist), and is also what
> dpkg uses to track conffiles changes, and is also part of the interface,
> where packages query those values to check whether files have changed
> from the original for example. There's been talk over the years to
> "upgrade" to stronger digest functions, but it's not been really
> pressing precisely because these are not intended for security purposes,
> and having a stronger digest might make people thing they are intended
> for security. Although using cryptographically broken digests means
> this tends to trigger people's alarm bells, so…
It popped up on my side due to popping in perf testing ;)
> This is supposedly documented in the deb-md5sums(5) man page, and
> perhaps should be made more clear in the man page documenting the
> «dpkg -V» option, so I'm happy to try to clarify these.
ach. Years ago I used something different for it. Good to know that dpkg
itself supports it.
> With the fsys metadata work, it will be easier to add new digests, but
> that implies an increase in db size or control members in .deb, so I'm
> not sure whether it's really worth it. There are people that want to
> also include per-file signatures (such as IMA stuff) in the mtree
> metadata in the .deb, so that would cover the security side of things,
> but that would go counter to reproducibility, so I'm not seeing that
> happening easily, and I expect there will probably be concerns about
> lock-in and similar.
Oh I see. So based on what I read, it is just a checksum kind of thing
so xxh128 would be a perfect replacement. But I do understand that you
need to maintain things and adding an additional digest means adding and
keeping the older one for compatibility reasons.
Since it popped on my perf testing, do we need to verify the md5sum
during installation? I tried installation of firefox (since it is a
little big) with libmd, openssl and then telling dpkg to just do nothing
and compare the runtime. I didn't do that because the installation
process involved man-db taking some time and I was worried that it might
fiddle with the results. Then I tried "dpkg-deb -x" but didn't see md5
in log so it seems to be skipped.
If adding a fast replacement is difficult could we skip doing the md5
check during installation?
> Thanks,
> Guillem
Sebastian
Reply to: