Bug#699114: O: libnss-ldap -- NSS module for using LDAP as a naming

2020-07-11 Thread Arthur de Jong
On Tue, 2020-07-07 at 22:04 +0200, Chris Hofstaedtler wrote:
> Do any of you think the situation has changed since 2013?
> 
> Personally I would not want to have once popular NSS and PAM
> libraries in the next stable release, if upstream has vanished a long
> time ago.

Looking at the popcon stats (which may not be very representative
because large workstation networks are unlikely to participate):
https://qa.debian.org/popcon-graph.php?packages=libnss-ldap%20libpam-ldap%20libnss-ldapd%20libpam-ldapd%20libnss-sss%20libpam-sss_installed=on_legend=on_ticks=on_fmt=%25Y-%25m=1

It seems that all three alternatives are currently about equally
popular. It does seem that the old implementation popularity is
steadily declining and sssd is gaining popularity.

There are still a few use cases for at least libpam-ldap that are not
covered by libpam-ldapd (e.g. #845681) (I don't know if sssd covers
those).

While upstream is inactive for both libnss-ldap and libpam-ldap for a
few years now, there do not appear to be any RC bugs in them. Given the
kind of code it is also unlikely that any new vulnerabilities will be
found in them which haven't been found in the last 15 years or so. If
they become a burden or risk I would be more eager to say remove them,
but the current costs of keeping them around is so low that the
benefits for their users probably outweigh them.

Then again, I don't have a very strong opinion on it so if someone has
a good reason to remove them I won't object. At least I'm not going to
step up to become maintainer of those packages ;).

Kind regards,

-- 
-- arthur - adej...@debian.org - https://people.debian.org/~adejong --



signature.asc
Description: This is a digitally signed message part


Bug#699114: O: libnss-ldap -- NSS module for using LDAP as a naming

2020-07-07 Thread Chris Hofstaedtler
Hi Arthur, Barry, Moritz,

* Arthur de Jong  [200707 20:02]:
> On Sun, 2013-01-27 at 19:25 +, Steve McIntyre wrote:
> > The current maintainer of libnss-ldap, Richard A Nelson (Rick)
> >  > orphan this package now.
> 
> If anyone is willing to be maintainer of the libnss-ldap and libpam-ldap
> packages I'm willing to help getting the packages into shape.

[..]

> I may also point people to libnss-ldapd and libpam-ldapd as alternatives
> (depending on whether anyone else is willing to do any work on this).

[..]

> The alternative is to remove the packages (see #717917 and #717918)
> which, while being good for the popularity of my packages ;), would
> perhaps not be the most ideal situation.

Do any of you think the situation has changed since 2013?

Personally I would not want to have once popular NSS and PAM
libraries in the next stable release, if upstream has vanished a long
time ago.

Maybe its time to reopen 717917 and 717918?

Chris



Bug#699114: O: libnss-ldap -- NSS module for using LDAP as a naming

2013-07-27 Thread Arthur de Jong
On Sun, 2013-01-27 at 19:25 +, Steve McIntyre wrote:
 The current maintainer of libnss-ldap, Richard A Nelson (Rick)
 cow...@debian.org, is apparently not active anymore. Therefore, I
 orphan this package now.

If anyone is willing to be maintainer of the libnss-ldap and libpam-ldap
packages I'm willing to help getting the packages into shape.

I'm the maintainer of nss-pam-ldapd (a replacement for both) but I'm not
looking to become maintainer of the above packages myself.

I'm also willing to get the packages into shape by:
- updating to the latest upstream versions
- switch to 3.0 (quilt) source format (converting patches)
- switch to dh sequencer
- more packaging cleanups
- try to fix most RC bugs and try to address some of the other bugs

I may also point people to libnss-ldapd and libpam-ldapd as alternatives
(depending on whether anyone else is willing to do any work on this).

I can make a QA upload of the above changes (depending on whether anyone
objects, speaks up or no-one responds). It would be best to have the
packages in some VCS somewhere (any suggestions?).

The alternative is to remove the packages (see #717917 and #717918)
which, while being good for the popularity of my packages ;), would
perhaps not be the most ideal situation.

Any comments?

-- 
-- arthur - adej...@debian.org - http://people.debian.org/~adejong --


signature.asc
Description: This is a digitally signed message part