[MIR] Promote ruby-daemons to main as a pcs indirect dependency

[Lucas Kanashiro]

[Availability]

The package ruby-daemons is already in Ubuntu universe.

The package ruby-daemons build for the architectures it is designed to work on.

It currently builds and works for architectures: amd64 (arch:all)

Link to package [[https://launchpad.net/ubuntu/+source/ruby-daemons|ruby-daemons]]

[Rationale]

The package ruby-daemons is required in Ubuntu main for thin promotion
which is a runtime dependency of pcs (the main reason for this promotion).

Ideally, we expect that ruby-daemons (and pcs) will be promoted in the "L" development cycle. The idea is to promote only the ruby-daemons binary.

[Security]

Required links:

https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=ruby-daemons

Nothing was found searching for the package name.

Nothing was found searching in the OSS security mailing list archive.

https://ubuntu.com/security/cves?package=ruby-daemons

Also nothing found in the Ubuntu security tracker.

No `suid` or `sgid` binaries.

No executables in `/sbin` and `/usr/sbin`.

Package does not install services, timers or recurring jobs.

Packages does not open privileged ports (ports < 1024).

Packages does not contain extensions to security-sensitive software
(filters, scanners, plugins, UI skins, ...).

[Quality assurance - function/usage]

The package works well right after install.

[Quality assurance - maintenance]

The package is maintained well in Debian/Ubuntu and has not too many
and long term critical bugs open

- Ubuntu https://bugs.launchpad.net/ubuntu/+source/ruby-daemons/+bug
- Debian https://bugs.debian.org/cgi-bin/pkgreport.cgi?src=ruby-daemons

The package does not deal with exotic hardware we cannot support.

[Quality assurance - testing]

The package runs a test suite on build time, if it fails
it makes the build fail, link to build log:

https://launchpadlibrarian.net/621299536/buildlog_ubuntu-kinetic-amd64.ruby-daemons_1.4.1-1_BUILDING.txt.gz

The package runs an autopkgtest, and is currently passing on
this list of architectures: amd64, arm64, armhf, ppc64el, s390x.

Link to test logs:

https://autopkgtest.ubuntu.com/packages/ruby-daemons

The package does not have failing autopkgtests right now. Only in i386, where some dependencies are not installable.

[Quality assurance - packaging]

debian/watch is present and works.

debian/control defines a correct Maintainer field.

Lintian overrides are not present. Here is the output of `lintian --pedantic` against Kinetic version:

W: ruby-daemons source: newer-standards-version 4.6.1 (current is 4.6.0.1)

This package does not rely on obsolete or about to be demoted packages.

The package will not be installed by default.

Packaging and build is easy, link to d/rules:

https://git.launchpad.net/~git-ubuntu-import/ubuntu/+source/ruby-daemons/tree/debian/rules

[UI standards]

Application is not end-user facing (does not need translation).

[Dependencies]

No further depends or recommends dependencies that are not yet in main.

[Standards compliance]

This package correctly follows FHS and Debian Policy.

[Maintenance/Owner]

Owning Team will be Server.

Team is not yet, but will subscribe to the package before promotion.

This does not use static builds.

This does not use vendored code.

This package is not rust based.

The package has been built in the archive more recently than the last
test rebuild.

[Background information]

The Package description explains the package well.

Upstream Name is: daemons.

Link to upstream project: https://github.com/thuehlinger/daemons

[Lukas Märdian (slyon)]

Review for Package: src:ruby-daemons

[Summary]
ruby-daemons is a wrapper which can put any ruby script into a daemonized
background process. Having approximately 188M downloads on rubygems.org
(as of Nov. 2022) it seems to be a quite popular gem.

MIR team ACK

This does not need a security review

List of specific binary packages to be promoted to main: ruby-daemons
Specific binary packages built, but NOT to be promoted to main: <None>

Notes:
- I was a bit concerned about Ruby's autodep8 tests being marked "skippable", as that could lead to (certain) test failures being treated as "neutral" and migrating broken packages. After reading a bit more into man
gem2deb-test-runner(1), I feel confident it should be working as expected.

- I am also concerned about the sporadic update history of ruby-daemons. There
seems to be not too much upstream activity and the package was just bumped to
the recent version for this MIR, skipping several years of updates in between.
It seems to be a pretty popular gem, though, and I hope we can improve the
update situation going forward, having the package in main and @lucaskanashiro
being the Debian maintainer as well.

Required TODOs: None \o/

Recommended TODOs:
#0 The package should get a team bug subscriber before being promoted
#1 warning during build (not sure if we can/should do anything about that):
dpkg-gencontrol: warning: Depends field of package ruby-daemons: substitution variable ${shlibs:Depends} used, but is not defined

[Duplication]
There is no other package in main providing the same functionality.
There are plenty of daemonizing gems available for ruby, some of which are in
the Ubuntu archive, too: https://www.ruby-toolbox.com/categories/daemonizing
None of those is in main, though.

[Dependencies]
OK:
- no other Dependencies to MIR due to this
  - SRCPKG checked with `check-mir`
  - all dependencies can be found in `seeded-in-ubuntu` (already in main)
  - none of the (potentially auto-generated) dependencies (Depends
    and Recommends) that are present after build are not in main
- no -dev/-debug/-doc packages that need exclusion
- No dependencies in main that are only superficially tested requiring
  more tests now.

Problems: None

[Embedded sources and static linking]
OK:
- no embedded source present
- no static linking
- does not have unexpected Built-Using entries
- not a go package, no extra constraints to consider in that regard
- not a rust package, no extra constraints to consider in that regard
- Does not include vendored code

Problems: None

[Security]
- 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 (files [images, video, audio,
  xml, json, asn.1], network packets, structures, ...) from
  an untrusted source.
- does not open a port/socket
- 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)
- does not deal with security attestation (secure boot, tpm, signatures)
- does not deal with cryptography (en-/decryption, certific...

[Lucas Kanashiro (lucaskanashiro)]

Thanks for the review Lukas!

Regarding #0, yes, the server team will be subscribed. And about #1, ${shlibs:Depends} is defined as a build dependency, this shouldn't be a problem.

Regarding maintenance, I will be personally taking care of those packages (pcs and friends) in Debian and keeping them updated and fixing important issues.

[Christian Ehrhardt  (paelzer)]

All questions answered - thanks Lucas.
Subscription was added.

This is ready, marking the state accordingly.
(Actually it was already good - in progress until the change that causes a component mismatch lands)

[Lucas Kanashiro (lucaskanashiro)]

The promotion of this package to main was needed because thin was a pcs dependency, however, upstream developers moved to puma (instead of thin), so this is not needed anymore.

https://github.com/ClusterLabs/pcs/pull/632