[MIR] libnet-snmp-perl as a dependency of amavisd-new

[Paride Legovini]

[Summary]
=========

Please promote bin:libnet-snmp-perl to main. It's the only binary package built by src:libnet-snmp-perl. The package is a "new" dependency of bin:amavisd-new, which is in main. I say "new" in quotes because is was already a dependency, but d/control missed it up to version 1:2.11.1-5, see [0].

[Rationale]
===========

libnet-snmp-perl is a runtime dependency of amavisd-new, which is in main.
The packages is not in main already because it was not specified in d/control, see [0]. According to the upstream release notes [2] this
has been the case since version 2.6.4. Note that Precise packages version
2.6.5 already.

The missing dependency is not immediately visible at such as it only
causes failures when using amavisd-snmp-subagent, a tool to facilitate the monitoring of the filtering system via snmp. The agent is shipped with
the amavisd-new package and therefore is in main.

[Availability]
==============

Upstream: the module exists since 1998. Upstream development doesn't
seem to be active, but OTOH this module like many others in the perl5
ecosystem can be considered in maintenance mode at this point.

Debian: libnet-snmp-perl was first packaged in Debian in 2000 and it's
actively maintained, see [3] and d/changelog.

Ubuntu: the package is a sync from Debian across all the supported Ubuntu releases (and also across the >=Precise unsupported ones).

It is unlikely that the library will be superseded or deprecated in the foreseeable future.

[Security]
==========

The package is a SNMP client library. It provides no daemons or services
in general, does not open ports, does not require special privileges to
operate, and does not install setuid binaries.

I see no need for looping in the security team.

[Quality assurance]
===================

Upstream has a test suite which is exercised during the .deb package build.

Debian has only one bug open against the package, which IIUC is about
how the module handles a non-RFC-compliant SNMP server. The bug has been
forwarded upstream, and IMO shouldn't be considered a blocker for main
inclusion.

Upstream bugs are tracked on CPAN [4]. The bug count is low given the
age of the project, with the latest ones being forwards from Debian.
I can see no red flags there.

Ubuntu has no bugs filed against the package.

[Dependencies]

Depends only on perl:any, so we're good here.

[Standards compliance]

The package is in good shape, it's well maintained and follows
standards and best practices. The only thing `lintian -EvIL +pedantic` complains about is:

X: libnet-snmp-perl source: debian-watch-does-not-check-gpg-signature

There are however two lintian overrides for the binary package:

libnet-snmp-perl: library-package-name-for-application usr/bin/snmpkey
libnet-snmp-perl: application-in-library-section perl usr/bin/snmpkey

Lintian is right, but apparently the Debian maintainers decided this is a wontfix. The fix would consist in splitting out a "-tools" package out of the "lib" one, I can see it's probably not worth it.

[Maintenance]
=============

The Server Team will maintain the package. The maintenance effort is expected to be very low.

[0] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=936052
[1] https://fastapi.metacpan.org/source/DTOWN/Net-SNMP-v6.0.1/Changes
[2] https://gitlab.com/amavis/amavis/-/blob/master/RELEASE_NOTES
[3] https://salsa.debian.org/perl-team/modules/packages/libnet-snmp-perl
[4] https://rt.cpan.org/Public/Dist/Display.html?Name=Net-SNMP

[Roland Rosenfeld (roland)]

I fear that you mixed up two packages here:

libnet-snmp-perl 6.0.1 with the Perl module Net::SNMP from https://metacpan.org/dist/Net-SNMP (unchanged upstream since 2010).

and

libsnmp-perl 5.9(.1) with the Perl modules SNMP and NetSNMP::* from https://net-snmp.sourceforge.io/ and http://github.com/net-snmp/net-snmp/

I don't know which of them is used by amavisd-ng, but libnet-snmp-perl 6.0.1 isn't updated upstream since 2010, but is actively maintained by the Debian Perl team (including me).

Greetings
Roland

[Paride Legovini (paride)]

Hi Roland, you are right, I mixed up the two upstreams, I updated the MIR bug description.

One thing I got right for sure is the part about the package being actively and well maintained. Thanks for chiming in!

[Didier Roche-Tolomelli (didrocks)]

[Summary]
Ack from the MIR team side, nothing special to note on this well-maintained package which should be low overhead. Thanks for the detailed description!

You should double check the bug subcription, the foundation team is subscribed to it, which is fine, but you mentioned server.

[Duplication]
There is no other package in main providing the same functionality.

[Dependencies]
OK:
- no other Dependencies to MIR due to this
- no -dev/-debug/-doc packages that need exclusion

[Embedded sources and static linking]
OK:
- no embedded source present
- no static linking

[Security]
OK:
- history of CVEs does not look concerning
- does not run a daemon as root
- does not use webkit1,2
- does not use lib*v8 directly
- does not parse data formats
- does not open a port
- does not process arbitrary web content
- does not use centralized online accounts
- does not integrate arbitrary javascript into the desktop
- does not deal with system authentication (eg, pam), etc)

[Common blockers]
OK:
- does not FTBFS currently
- does have a test suite that runs at build time
- test suite fails will fail the build upon error.
- do not have or justify a test suite that runs as autopkgtest
- The package has a team bug subscriber (Foundations and not server though)
- no translation present, but none needed for this case (user visible)?
- not a python/go package, no extra constraints to consider int hat regard

[Packaging red flags]
OK:
- Ubuntu does not carry a delta
- symbols tracking not applicable for this kind of code.
- d/watch is present and looks ok
- Upstream update history is slow, but the upstream code is stable
- Debian/Ubuntu update history is good
- the current release is packaged
- promoting this does not seem to cause issues for MOTUs that so far
- no massive Lintian warnings
- d/rules is rather clean
- Does not have Built-Using

[Upstream red flags]
OK:
- no Errors/warnings during the build
- no incautious use of malloc/sprintf (as far as I can check it)
- no use of sudo, gksu, pkexec, or LD_LIBRARY_PATH
- no use of user nobody
- no use of setuid
- no important open bugs (crashers, etc) in Debian or Ubuntu
- no dependency on webkit, qtwebkit, seed or libgoa-*
- not part of the UI for extra checks

[Didier Roche-Tolomelli (didrocks)]

Override component to main
libnet-snmp-perl 6.0.1-6 in impish: universe/perl -> main
libnet-snmp-perl 6.0.1-6 in impish amd64: universe/perl/optional/100% -> main
libnet-snmp-perl 6.0.1-6 in impish arm64: universe/perl/optional/100% -> main
libnet-snmp-perl 6.0.1-6 in impish armhf: universe/perl/optional/100% -> main
libnet-snmp-perl 6.0.1-6 in impish i386: universe/perl/optional/100% -> main
libnet-snmp-perl 6.0.1-6 in impish ppc64el: universe/perl/optional/100% -> main
libnet-snmp-perl 6.0.1-6 in impish riscv64: universe/perl/optional/100% -> main
libnet-snmp-perl 6.0.1-6 in impish s390x: universe/perl/optional/100% -> main
Override [y|N]? y
8 publications overridden.