#624768 O: libnss-db -- NSS module for using Berkeley Databases as a naming service

Package:
wnpp
Source:
wnpp
Submitter:
Ondřej Surý
Date:
2025-11-28 22:19:02 UTC
Severity:
normal
#624768#5
Date:
2011-05-01 13:28:01 UTC
From:
To:
Hi,

I propose libnss-db removal from testing and stable, because it:

- has a serious security bug in stable and testing
- is unmaintained in upstream (removed from glibc, no upstream)
- is unmaintained in Debian (security bug open for year)

O.
#624768#10
Date:
2011-05-01 13:57:09 UTC
From:
To:
Removal from stable isn't going to happen.  As to testing, what's the
alternative for nss-db users, such as, say, *.debian.org?

Cheers,
Julien
#624768#17
Date:
2011-05-02 12:30:13 UTC
From:
To:
2011/5/1 Julien Cristau <jcristau@debian.org>:

Ok, no problem.

One alternative would be to adopt the package both in debian and as a
upstream (or convince (e)glibc people to pick it up) and care about it
if it's important for Debian.

I don't know the Debian infrastructure enough to be able to answer the
question, but wouldn't libnss-ldap do the job - DD accounts are stored
in LDAP, aren't they?

O.
#624768#22
Date:
2011-05-02 17:54:06 UTC
From:
To:
AIUI libnss-ldap means if your connection to the ldap server goes down
temporarily for some reason you're locked out until it comes back.  That
seems bad for a setup like debian's which is heavily distributed.  So
currently the account data is synchronized with ud-replicate and cron,
and imported into bdb files for libnss-db use.

Cheers,
Julien
#624768#27
Date:
2011-05-02 18:11:51 UTC
From:
To:
I am Ccing the DSA team, because this affect them most...

Well, libnss-ldap(d) + NSCD could do the trick for short offline
periods (with HA LDAP setup).

http://wiki.debian.org/LDAP/NSS

Same for PAM+LDAP:

http://wiki.debian.org/LDAP/PAM

However I am not strongly pushing one way (the upstream-adoption) or
another (the ldap+nscd) - however I feel that depending on
unmaintained software with a year-old security bug isn't really a good
option.

O.
#624768#32
Date:
2011-05-02 20:58:56 UTC
From:
To:
I don't think libpam-ldap would meet our requirements.  And nscd is best
avoided.
#624768#37
Date:
2011-05-03 15:39:43 UTC
From:
To:
retitle 624768 RFH: libnss-db
reassign 624768 wnpp
thank you

Then somebody should step-up and give a libnss-db little love. It's
shame we couldn't push it to GSoC now :(. Unfortunately it's so far
away from DNS as it could be, so I am probably not be able to adopt it
in our labs and I have already too many tasks on my shoulder. So I
cannot really promise anything, but if I catch some spare cycles
somewhere and nothing happens here, I'll at least fix the security
issue and libdb transition in a NMU. However I still think that from a
long term this needs to be

Reassigning to wnpp as a RFH and Ccing 604854 (which is about building
libnss-db from eglibc).

O.
#624768#56
Date:
2017-01-27 16:41:24 UTC
From:
To:
Dear Customer,



We can not deliver your parcel arrived at January 23.



Download postal receipt attached to e-mail!



Your help is greatly appreciated,

Thomas Johnston,

USPS Senior Delivery Manager.
#624768#61
Date:
2020-01-16 05:22:22 UTC
From:
To:
I just learned of this bug via the action needed list on
tracker.debian.org/pkg/nsscache; nsscache and libnss-cache are designed
specifically to handle the requirements described in message #22 and
onwards, fyi.