Hi Yan, On 2026-03-29 23:43, Fitterer, Yan wrote: > Package: glibc > Version: 2.42-14 > Severity: wishlist > > Debian currently skips building the libnss-db library from the glibc > codebase. Instead, it provides a separate libnss-db package based on an older > standalone codebase. > > That standalone codebase was split out of glibc around 2012, when Oracle > acquired BerkeleyDB and glibc moved its nss-db backend to a BerkeleyDB-free > implementation with an incompatible on-disk format. The Debian libnss-db > package is therefore based on an old, now largely unmaintained > implementation, which has a number of bugs. > > In particular: > - it performs poorly during enumeration because of redundant openat() calls; > - it can occasionally cause initgroups() to set incorrect group membership > at login, because getgrouplist() is not thread-safe. > > I can provide reproducers for those bugs if useful, but those are separate > issues; I mention them here only as context and motivation for this request.
One of the main reason to use the separate libnss-db package based on BerkeleyDB is that the file format is architecture independent. At that time, it was not the case of the glibc implementation. Do you know if it is still the case? This is important in the multilib and multiarch context. That said as db5.3 is scheduled for removal from the archive, I understand that you are investigating alternatives. One of them is libnss-cache, although the file format is quite different. > The glibc implementation is of better quality and would be a worthwhile > alternative. I am preparing an MR in Salsa to make a new libc6-libnss-db > package as part of glibc to address this issue. This package is functionally > identical to the current libnss-db package and can replace it, although both > packages cannot be installed at the same time. I have added a few comment to your MR. This doesn't mean it will get accepted once fixed, we need to understand the limitation of the glibc version first. Regards Aurelien -- Aurelien Jarno GPG: 4096R/1DDD8C9B [email protected] http://aurel32.net
