I recently ran into this same issue and dug into it for a while. The real problem stems from https://sourceware.org/bugzilla/show_bug.cgi?id=23960. The issue is that glibc 2.28 changed readdir to always use getdents64. This causes problems when you're running a 32 bit guest in QEMU on a 64 bit host. So, this would also affect running an i386 guest on an x86_64 host, for example.
The issue is that rehash calls OPENSSL_DIR_read on the certificate directory. This is actually just a wrapper around readdir. However, if you compile openssl (really libcrypto) with large file support, then glibc actually uses readdir64, which will use a dirent64 structure that doesn't have the overflow issues that the regular dirent structure has in this situation. After building openssl locally with future=+lfs in DEB_BUILD_MAINT_OPTIONS, I was able to get the right behavior. Here's a comparison (certs is just a local directory with one of the symlinks from /etc/ssl/certs copied into it). Current behavior: root@talkbox:~# /qemu-arm-static -strace /usr/bin/openssl rehash certs/ 2>&1 | grep getdents64 20411 getdents64(3,-13637592,32768,-559685376,-13637592,-622472) = 128 With LFS libcrypto: root@talkbox:~# LD_LIBRARY_PATH=libssl1.1-patched/usr/lib/arm-linux-gnueabihf /qemu-arm-static -strace /usr/bin/openssl rehash certs/ 2>&1 | grep getdents64 20402 getdents64(3,-13637592,32768,0,32,-13637624) = 128 20402 getdents64(3,-13637592,32768,128,32,-13637624) = 0 And just the normal rehash output: root@talkbox:~# openssl rehash -v certs/ Doing certs/ root@talkbox:~# LD_LIBRARY_PATH=libssl1.1-patched/usr/lib/arm-linux-gnueabihf/ openssl rehash -v certs/ Doing certs/ link thawte_Primary_Root_CA.pem -> 2e4eed3c.0 So, I think there are a few options on what to do. 1. Change update-ca-certificates back to using c_rehash. Presumably perl is built with LFS and it's readdir wrapper DTRT. 2. Build openssl with LFS as noted above. 3. Wait for a fix to be hashed out between the glibc, kernel and qemu folks. -- Dan Nicholson | +1.206.437.0833 | Endless
