Status and future of libembperl-perl

[intrigeri <intrigeri@boum.org>]

Hi,

while looking for potential removal candidates, I somewhat randomly
stumbled upon libembperl-perl, whose current version in the archive is
2.5.0-15. Yes, -15, because it looks like upstream became inactive in
2014, and since then, members of our team adapted upstream code for
every change in the surrounding ecosystem:

 - perl 5.20
 - perl 5.22
 - Apache 2.4.0
 - CGI.pm >= 4.04
 - PERL_USE_UNSAFE_INC being disabled by default in perl 5.26
 - perl 5.28
 - Apache 2.4.40
 - {xml2,xslt}-config going away ⇒ switch to pkg-config
 - current GCC (-Wmisleading-indentation)

Most of these patches were forwarded upstream, yielding no
reaction there.

So, let's face it: we've de facto been maintaining the upstream code
base since 6 years. I expect that if we keep this package in Debian,
we'll have to keep doing this on a regular basis.

Is this what we want?

Personally, I'm concerned by this situation for 2 reasons:

 - This package is security sensitive: it's a "system for building
   dynamic websites with Perl". I suppose some of these websites
   are exposed publicly on Internet (<shudder>).

   For example, a security issue (#731996, infoleak trivially
   triggered remotely) was reported to us + upstream in 2014,
   and not addressed yet.

   More generally, sloccount tells me that half of the code base is
   written in C. I don't think we're doing a great service to our
   users by giving them the means to build websites using a framework
   written in a memory-unsafe language.

 - Is it the best use of our limited resources to maintain a de facto
   fork of this unmaintained, and not very popular anymore, upstream
   code base?

   I see that popcon has been steadily decreasing since 2012;
   currently, inst = 39.

I propose we do this:

1. Remove it from testing, in order to:

    - Send a strong signal to Debian users who still rely on this
      module, by *not* including it in Bullseye. Hopefully the few
      remaining users will notice and migrate to something else, or
      decide they care enough about the status quo to adopt this
      module upstream.

    - Decrease the urgency of future problems in this module: e.g.
      they won't be blocking perl-5.xy upgrades and migrations anymore.

2. Keep it in sid until next time it badly breaks.

   Depending on when this happens, on whether someone else than us
   paid attention and took over upstream maintenance, and on the
   feedback we got from step (1), then we can reconsider our options.

I certainly wouldn't mind removing it from sid now, but I know I don't
represent the current consensus on our team wrt. trigger-happiness for
removing packages, hence this more iterative proposal :)

Thoughts?

Cheers!