[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: [PATCH] libdpkg: Use OpenSSL for hashing.



Hi!

On Sat, 2023-07-01 at 00:03:53 +0200, Sebastian Andrzej Siewior wrote:
> This a quick hack to get some feedback regarding this change: Use
> OpenSSL crypto library for hashing instead of libmd.
> OpenSSL provides a slightly assembly optimized version for amd64 while
> libmd is pure C. This passes the testsuite and I was able to perform an
> upgrade so it can't be that bad ;) If I read this right, the checksum is
> computed during package installation.
> 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.)

> While at it, why do we use md5? I'm asking because a small upgrade to
> sha1 would improve the performance since sha1 performs better on
> architectures that provide optimisation for it which includes a lot.
> _If_ we are changing things here then we could decide if something like
> checksum (e.g. xxhash) is enough to catch a bitflip or if a
> cryptographic checksum is really required.

> I don't know _why_ we have it: The .deb file was verified by apt after
> the download, the decompressor has also a checksum.
> The md5sum file isn't signed in any way, so whoever modified the binary
> in the system could update md5sum file in case it is verified later.

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…

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.


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.

Thanks,
Guillem


Reply to: