[MIR] needrestart + dependencies

[Christian Ehrhardt ]

[Availability]

The package and its dependencies are already in universe.

[Rationale]

needrestart is a very useful maintenance tool to track any processes
that are out of date, and when possible offer to restart them. This
tool is very useful to check if sessions need to be restarted,
workloads need restarting, user & system daemons need restarting. But
also, whether the restarts were successful. This is part of the work towards us having to restart less.

It requires some perl dependencies pulled in, but they're mostly just your typical additional perl modules.

[Security]

The needrestart package is around in Ubuntu and Debian since many years (first upload in Debian in 2013). Since then, there have been no CVE's or serious security vulnerabilities reported (+ no mention of any security related fixes in the changelog). It installs the needrestart perl script into /usr/sbin/, no setuid binaries present.

As for its runtime dependencies:

- libintl-perl: in 2016 CVE-2016-1238 has been addressed
- libmodule-find-perl: none
- libmodule-scandeps-perl: none
- libsort-naturally-perl: none

(all the dependencies are perl modules, so no security-interesting binaries/configurations are being installed)

[Quality assurance]

The package, after installation, is ready without any special configuration. needrestart is already seeded as per [1]. Also, as mentioned in the Maintenance section, the package is regularly updated in Debian (directly synced to Ubuntu as of now).
Browsing through Ubuntu and Debian bugs filled for needrestart, there seem to be none that are particularly worrisome. Most of them are old bugs, possibly no longer relevant. Some that we might want to check up on if they're still a thing:
- https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=826044 - seems like the last post was in 2018 and no new reports
- https://bugs.launchpad.net/ubuntu/+source/needrestart/+bug/1734768 - from 2017, xenial, old, but maybe worth re-visiting just in case

Browsed the upstream bugs as well and saw nothing critical there as well (microcode issues on bionic, but that's fixed in later versions).

And all required dependencies seem to have no outstanding bugs in Ubuntu.

[Dependencies]

All dependencies are either already in main or are part of this MIR. There are a few additional universe build-dependencies (and build-dependencies of the dependencies) but those have been confirmed to only be used during the build and not result in any other universe runtime dependencies.

[Standards compliance]

FHS and Debian Policy compliant.

[Maintenance]

The Ubuntu Foundations Team will be subscribed to the package and its relevant dependencies. All the packages seem to be actively maintained in Debian and so far no additional Ubuntu changes were required.

[Background information]

The package is already seeded, as for 21.04 we'd like to aim to force people to restart less. And this tool will be very useful for us to achieve that.

[Original Description]

This is a stub for coming MIR activity.
Since this was already seeded [1] it regularly shows up as component mismatch now.

Therefore we want to raise this from "status is unknown" to "nothing done yet, but documented as that" :-)

The bug status will be incomplete util properly prepared.

This covers needrestart and it's dependencies:
- libintl-perl
- libmodule-find-perl
- libmodule-scandeps-perl
- libsort-naturally-perl

[1]: https://git.launchpad.net/~ubuntu-core-dev/ubuntu-seeds/+git/ubuntu/commit/?id=ed7003d4c9a0be80e8a17699baa858b2bf1ce06b

[Launchpad Janitor (janitor)]

[Expired for libmodule-scandeps-perl (Ubuntu) because there has been no activity for 60 days.]

[Launchpad Janitor (janitor)]

[Expired for libsort-naturally-perl (Ubuntu) because there has been no activity for 60 days.]

[Launchpad Janitor (janitor)]

[Expired for libintl-perl (Ubuntu) because there has been no activity for 60 days.]

[Launchpad Janitor (janitor)]

[Expired for libmodule-find-perl (Ubuntu) because there has been no activity for 60 days.]

[Launchpad Janitor (janitor)]

[Expired for needrestart (Ubuntu) because there has been no activity for 60 days.]

[Christian Ehrhardt  (paelzer)]

FYI - MIR review assignments done in MIR Team meeting.

[Christian Ehrhardt  (paelzer)]

[Summary]
MIR Ack once the subscription is added (incomplete until then, as we have not
yet defined the process to have the AAs check this and I don't want to create
a trap for them)
This does not need a security review.

List of specific binary packages to be promoted to main: libmodule-find-perl

Required TODOs:
Get the Foundations Team subscribed to the package before promoting it to main.

[Duplication]
libmodule-reader-perl is similar to some extend, but not in main - so no
problem.

[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)

Problems:
A program can not open more/less modules due to this. Also the modules
that you'd usually directly open are of the same security level (e.g. who can
write to them) as those searched and loaded by this.
It is also not a lot of code and doesn't have too complex structures
to break/exploit things that were overlooked.
So I think this does not make it "more insecure" and does not need a security
review.

[Common blockers]
OK:
- does not FTBFS currently
- does have a test suite that runs at build time
  - test suite will fail upon error.
- does have a test suite that runs as autopkgtest (the auto perl ones)
- no translation present, but none needed for this case
- not a python/go package, no extra constraints to consider in that regard

Problems:
- The package has a team bug subscriber

[Packaging red flags]
OK:
- Ubuntu does not carry a delta
- symbols tracking is in place
- d/watch is present and looks ok
- Upstream update history is slow but given this tool is small that is ok
- Debian/Ubuntu update history is sporadic (based on slow upstream changes)
- the current release is packaged
- promoting this does not seem to cause issues for MOTUs that so far
  maintained the package
- no massive Lintian warnings
- d/rules is rather clean (=the minimum)
- Does not have Built-Using

[Upstream red flags]
OK:
- no Errors/warnings during the build
- no incautious use of malloc/sprintf (perl)
- 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 or Upstream
- no dependency on webkit, qtwebkit, seed or libgoa-*
- not part of the UI for extra checks

[Łukasz Zemczak (sil2100)]

Thank you for the review Christian! I have now subscribed Ubuntu Foundations Bugs to all the packages in this MIR.

[Christian Ehrhardt  (paelzer)]

Thanks, thereby libmodule-find-perl is ready then.
Let us see how it overall looks once the other got to do their reviews.

[Didier Roche-Tolomelli (didrocks)]

[Summary]
We need to assess the situation of package updates. We are several releases behind (5 years behind) and have some CVE as distro-patch as a consequence. Some DD just took it over in January it seems, but didn’t update to current releases.

List of specific binary packages to be promoted to main: libintl-perllib libintl-xs-perl

Required TODOs:
- Assess the package update situation and health of the debian team responsible for it.

[Duplication]
Other perls modules deals with i18n, but it seems none give the same gettext functionality.

[Dependencies]
OK:
- no other Dependencies to MIR due to this (perlapi-5.32.1 is a virtual package provided by perl-base)
- 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 will fail upon error.
- does have a test suite that runs as autopkgtest
- no translation present, but none needed for this case
- not a python/go package, no extra constraints to consider in that regard

[Packaging red flags]
OK:
- Ubuntu does not carry a delta
- no symbols tracking for this kind of libs
- d/watch is present and looks ok
- Upstream update history is good
- promoting this does not seem to cause issues for MOTUs that so far
- no massive Lintian warnings
- d/rules is rather clean (=the minimum)
- Does not have Built-Using

Problems:
- Debian/Ubuntu update history is not good: we are several release behind (1.26 released in 2016 and curent is 1.32), some CVS has been distro-patched due to this.
- the current release is not packaged and lagging behind (the version

[Upstream red flags]
OK:
- no Errors/warnings during the build
- no incautious use of malloc/sprintf (perl)
- 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 or Upstream
- no dependency on webkit, qtwebkit, seed or libgoa-*
- not part of the UI for extra checks

[gregor herrmann (gregoa)]

On Fri, 26 Feb 2021 15:25:09 -0000, Didier Roche wrote:

> [Summary]
> We need to assess the situation of package updates. We are several
> releases behind (5 years behind) and have some CVE as distro-patch
> as a consequence. Some DD just took it over in January it seems,
> but didn’t update to current releases.

It is maintained under the umbrella of the Debian Perl Group now
after havin been orphaned for some time.

The reason at least I haven't looked at the newer upstream releases
is that Debian is in Soft Freeze and libintl-{xs-,}perl have high
installation counts, so changes might be disruptive at this point.

HTH,
gregor, Debian Perl Group.

--
 .''`. https://info.comodo.priv.at -- Debian Developer https://www.debian.org
 : :' : OpenPGP fingerprint D1E1 316E 93A7 60A8 104D 85FA BB3A 6801 8649 AA06
 `. `' Member VIBE!AT & SPI Inc. -- Supporter Free Software Foundation Europe
   `- NP: Mark Knopfler: Wanderlust

[Didier Roche-Tolomelli (didrocks)]

Thanks Gregor for the feedback! Ack from the MIR team side then.

[Dan Streetman (ddstreet)]

[Summary]
There does not appear to be any significant problems with this
package from MIR perspective, with the sole exception of the lack
of any test suite.

This does not need a security review

List of specific binary packages to be promoted to main:
  - needrestart

Notes:
Besides the TODOs listed below, this needs to wait for its
dependencies to be approved and promoted to main

Required TODOs:
Some kind of test suite should be added, and run (at least) at build
time.

Recommended TODOs:
The 'prerequisite not found' build warnings appear harmless, but could
be fixed (I think) by adding the packages to the Build-Dep list

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

[Dependencies]
OK:
- no -dev/-debug/-doc packages that need exclusion

Problems:
- has other Dependencies to MIR due to this, which are all in progress using same LP bug
  - libintl-perl
  - libsort-naturally-perl
  - libmodule-scandeps-perl
  - libmodule-find-perl

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

[Security]
OK:
- no CVEs
- 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
- The package has a team bug subscriber (foundations)
- has translation
- not a python/go package, no extra constraints to consider in that regard

Problems:
- does not have a test suite

[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 good
- Debian/Ubuntu update history is good
- the current release is packaged
- promoting this does not seem to cause issues for MOTUs that so far
  maintained the package (no Ubuntu delta)
- no massive Lintian warnings
- d/rules is rather clean
- Does not have Built-Using
- not Go package

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

Problems:
- minor warnings during the build:
  Warning: prerequisite Module::ScanDeps 0 not found.
  Warning: prerequisite Proc::ProcessTable 0 not found.
  Warning: prerequisite Sort::Naturally 0 not found.
  Warning: prerequisite Term::ReadKey 0 not found.

[Dan Streetman (ddstreet)]

marking as incomplete due to lack of any test suite for needrestart. also optionally might be good to add missing build-deps

[Łukasz Zemczak (sil2100)]

Hey Dan! Thank you for your review.

I understand that needrestart as is now has no testing story, which is quite unfortunate. Do you have some testing scenario that you would consider as a minimum requirement for the package to get accepted into main? needrestart is a project which we are not upstream for, meaning that adding really useful tests would ultimately require help from upstream. Realistically, the only test I can tinker up before 21.04 is ready would be a very very simple autopkgtest that would be running the needrestart command and checking its output. Even then, well, we'd be introducing a delta against Debian - as I'm not confident that Debian would be willing to accept something as simple as that.

This is something that has not been tackled since long. Debian has a wishlist bug open for it since 2016:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=810584

Other than that, the source includes no testing as well, it's a very specific fruitcake. It's unfortunate, as I guess the perl module might have had some unit testing specified, but adding that without upstream approval would be weird.

Seeing that it's late in the cycle and so far the regression history of the package is rather low, could we settle on us reaching out both upstream and to Debian regarding test-story improvements and in the meantime accepting the package into main as is? Or, if that's in any way helpful, additionally creating such an 'easy' sanity-test autopkgtest (+ sending it to Debian to get rid of the delta)?

Cheers!

[Dan Streetman (ddstreet)]

I think that more extensive tests should be added in the next cycle, but for now I think at minimum basic functionality should be checked, for example just a simple autopkgtest like:

$ sudo needrestart -q -r l

(check for nothing currently needing restart)

$ LIBC=$(realpath /lib/x86_64-linux-gnu/libc.so.6)
$ sudo cp "$LIBC" "${LIBC}.new"
$ sudo mv -f "${LIBC}.new" "$LIBC"

$ sudo needrestart -q -r l

(check for things that need restart)

[Matthias Klose (doko)]

libsort-naturally-perl

 - upstream:
   - last release seven years ago
   - a few wishlist bug reports
   - no CVE's

- Debian
  - maintained by the Debian Perl Group
  - no open bug reports

A very small library providing two sort routines. Ok to promote.

[Matthias Klose (doko)]

libsort-naturally-perl

 - upstream:
   - last release 2021
   -no open bug reports
   - no CVE's

- Debian
  - maintained by the Debian Perl Group
  - no open bug reports

A small library to scan code for imports. Ok to promote.

[Matthias Klose (doko)]

so the question, why do we need that at all? we already have checkrestart (debian-goodies) in main. Instead of needrestart doing heuristics on used files/libraries, it just uses dpkg to dermine file to package relationships, and should catch more issues than needrestart.

[Dimitri John Ledkov (xnox)]

checkrestart only checks packaged things, whereas needrestart also monitors and offers to restart unpackaged end-user created daemons, user-session processes, runtime ephemeral scopes and things that might be unsupervised at all. overall checkrestart is insufficient to identify and restart things that may still be using vulnerable libssl for example.

[Matthias Klose (doko)]

ok, but why does it need libmodule-scandeps-perl? used for scanning perl modules?

xnox
:
10:52

as far as i can tell, it is used by /perl/lib/NeedRestart/Interp/Perl.pm which is a plugin to scan and detect which perl processes have which perl modules loaded (i.e. even those that are pure perl). And if they have been upgraded, try to surface that said perl processes need to be restarted.

10:53
It has similar thing for java too.

10:53
which is a bit confusing, because it is kind of duplicate work.

10:56
ah, but is needed for the unsupervised processes.

doko
:
12:06

but wouldn't be a solution better for that which just uses the package dependencies?

[Łukasz Zemczak (sil2100)]

Regarding needrestart per-se: Dan, I pushed a new version of needrestart to hirsute including a sanity-test autopkgtest - could you take a look if that is good enough? One note: currently the test is failing on armhf (but not blocking, as this was the first time it ran). The reason for that is that apparently kernel checking does not work on armhf right now. Basically what is happening is that needrestart is skipping kernel checks, which is something the test does not expect.

I was thinking of making the test skip the kernel checks if they cannot be performed, but then again I think this might be an actual regression in the current needrestart version. Which makes me think if maybe we should leave it as is and simply report it upstream - because I don't see this mentioned as a 'known issue'. I see Debian had a bug for armhf kernel detection not working in 2015 [1], but this seemed to be fixed in 2016 with needrestart 1.8. So I'd expect armhf having full functionality.

Anyway, right now needrestart has migrated to release. I'll send a bug report to Debian about armhf and forward the autopkgtest, if you're fine with how it looks right now. Do you think if I can promote all the things to main now? Thanks!

[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=800720

[Dan Streetman (ddstreet)]

> The reason for that is that apparently kernel checking does not work on armhf right now

are you sure it's an issue with armhf kernel checking? My guess would be it's a problem with kernel checking from inside an unprivileged container.

> Do you think if I can promote all the things to main now?

yep, while it would be good to expand the test (and fix issues the testing finds) that can happen in later cycles, the test is enough for ACK from MIR perspective, thanks!

[Dan Streetman (ddstreet)]

moved needrestart to fix-committed, i think all the packages are ready to promote to main now

[Łukasz Zemczak (sil2100)]

Thanks Dan! I'll try to dig into that a bit more later this week to see what it is. But seeing that arm64 and all other arches were fine (and this only happening on armhf), this was my first assumption. But let me actually run this with some verbosity on the actual infra. I wanted to reproduce it on the cloud manually, but hirsute apparently has issues with armhf images - but I do have a few other ideas. Anyway, I'm on it!

In the meantime, let me promote these to main.

[Łukasz Zemczak (sil2100)]

First, all the dependencies (promoted all sources and only the binaries that are needed):

Override component to main
libintl-perl 1.26-3 in hirsute: universe/perl -> main
libintl-perl 1.26-3 in hirsute amd64: universe/perl/optional/100% -> main
libintl-perl 1.26-3 in hirsute arm64: universe/perl/optional/100% -> main
libintl-perl 1.26-3 in hirsute armhf: universe/perl/optional/100% -> main
libintl-perl 1.26-3 in hirsute i386: universe/perl/optional/100% -> main
libintl-perl 1.26-3 in hirsute ppc64el: universe/perl/optional/100% -> main
libintl-perl 1.26-3 in hirsute riscv64: universe/perl/optional/100% -> main
libintl-perl 1.26-3 in hirsute s390x: universe/perl/optional/100% -> main
libmodule-find-perl 0.15-1 in hirsute: universe/perl -> main
libmodule-find-perl 0.15-1 in hirsute amd64: universe/perl/optional/100% -> main
libmodule-find-perl 0.15-1 in hirsute arm64: universe/perl/optional/100% -> main
libmodule-find-perl 0.15-1 in hirsute armhf: universe/perl/optional/100% -> main
libmodule-find-perl 0.15-1 in hirsute i386: universe/perl/optional/100% -> main
libmodule-find-perl 0.15-1 in hirsute ppc64el: universe/perl/optional/100% -> main
libmodule-find-perl 0.15-1 in hirsute riscv64: universe/perl/optional/100% -> main
libmodule-find-perl 0.15-1 in hirsute s390x: universe/perl/optional/100% -> main
libmodule-scandeps-perl 1.30-1 in hirsute: universe/perl -> main
libmodule-scandeps-perl 1.30-1 in hirsute amd64: universe/perl/optional/100% -> main
libmodule-scandeps-perl 1.30-1 in hirsute arm64: universe/perl/optional/100% -> main
libmodule-scandeps-perl 1.30-1 in hirsute armhf: universe/perl/optional/100% -> main
libmodule-scandeps-perl 1.30-1 in hirsute i386: universe/perl/optional/100% -> main
libmodule-scandeps-perl 1.30-1 in hirsute ppc64el: universe/perl/optional/100% -> main
libmodule-scandeps-perl 1.30-1 in hirsute riscv64: universe/perl/optional/100% -> main
libmodule-scandeps-perl 1.30-1 in hirsute s390x: universe/perl/optional/100% -> main
libsort-naturally-perl 1.03-2 in hirsute: universe/perl -> main
libsort-naturally-perl 1.03-2 in hirsute amd64: universe/perl/optional/100% -> main
libsort-naturally-perl 1.03-2 in hirsute arm64: universe/perl/optional/100% -> main
libsort-naturally-perl 1.03-2 in hirsute armhf: universe/perl/optional/100% -> main
libsort-naturally-perl 1.03-2 in hirsute i386: universe/perl/optional/100% -> main
libsort-naturally-perl 1.03-2 in hirsute ppc64el: universe/perl/optional/100% -> main
libsort-naturally-perl 1.03-2 in hirsute riscv64: universe/perl/optional/100% -> main
libsort-naturally-perl 1.03-2 in hirsute s390x: universe/perl/optional/100% -> main
Override [y|N]? y
32 publications overridden.

[Łukasz Zemczak (sil2100)]

And now needrestart:

Override component to main
needrestart 3.5-2ubuntu1 in hirsute: universe/misc -> main
needrestart 3.5-2ubuntu1 in hirsute amd64: universe/admin/optional/100% -> main
needrestart 3.5-2ubuntu1 in hirsute arm64: universe/admin/optional/100% -> main
needrestart 3.5-2ubuntu1 in hirsute armhf: universe/admin/optional/100% -> main
needrestart 3.5-2ubuntu1 in hirsute i386: universe/admin/optional/100% -> main
needrestart 3.5-2ubuntu1 in hirsute ppc64el: universe/admin/optional/100% -> main
needrestart 3.5-2ubuntu1 in hirsute riscv64: universe/admin/optional/100% -> main
needrestart 3.5-2ubuntu1 in hirsute s390x: universe/admin/optional/100% -> main
Override [y|N]? y
8 publications overridden.

[Dan Streetman (ddstreet)]

> But seeing that arm64 and all other arches were fine (and this only happening on armhf), this was my first assumption

yep it could be, I just assumed it was a container issue since armhf is the only arch where we run autopkgtests inside an lxd container instead of qemu instance.

[Łukasz Zemczak (sil2100)]

Yeah, checked some more verbose logs, looks like indeed needrestart detects being in a container and simply skips the kernel checks. I guess it might be a good idea for me to skip this particular test whenever we're running inside a container.