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

Review for Package: src:ruby-rack

[Summary]
Ruby rack is a popular middleware/framework for developing web applications,
using Ruby (not quite as popular as "Rails", though). It is well maintained
and I have not found another ruby based web framework in main.

MIR team ACK under the constraint to resolve the below listed
required TODOs and as much as possible having a look at the
recommended TODOs.

This does need a security review, so I'll assign ubuntu-security

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

Notes:
This is a middleware, exposed to the public interwebs, parsing HTTP requests.
Also, it has a history of CVEs in addition to https://bugs.debian.org/946983
So I'm assigning ~ubuntu-security.

Required TODOs:
#0 current release NOT packaged, new major version 3.0.0 available as of 09/22

Recommended TODOs:
#1 The package should get a team bug subscriber (Server team) before being promoted
#2 Debian/Ubuntu update history is a bit slow, we should try to improve this moving forward (We have DDs as uploaders, so that should be fine)
#3 Lintian suggestion:
P: ruby-rack source: maintainer-manual-page [debian/rackup.1]
The maintainer keeps a manual page in ./debian. Please forward the manual
page upstream and ask them to include in their version control system, and
in their next release.

#4 three classes of warnings during build (see below for logs):
(1) should (xargs options) be fixed
(2) we probably can't do anything about it right now
(3) should be discussed with upstream

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

https://www.ruby-toolbox.com/categories/web_app_frameworks
Rack seems to be a popular and well maintained Ruby middleware, but here are
other web frameworks for Ruby, notably src:rails which is even more popular.
None of those is currently 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]
OK:
- does not run a daemon as root
- does not use webkit1,2
- does not use lib*v8 directly
- 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, certificates, signing, ...)

Problems:
- does parse data formats (network packets) fr...

Thanks for the review Lukas!

I have been working on the update to version 3.0.0 in Debian but it will take some time. This is a major version bump and there are some breaking changes, I'll be uploading it to experimental and call for testing before moving it to unstable (and then sync into Ubuntu). Moreover, the rackup command was extracted from ruby-rack in this new release, this change will require the inclusion of ruby-rackup in the archive. I already filed an ITP bug for that here:

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1023708

FWIW I will be adding myself to the Uploaders list of both packages so we can more easily keep things updated.

Regarding forwarding the manpage to upstream, I do not think this is needed. TBH the manpage seems to be outdated, and it shouldn't be generated manually, we should generate it during build time. I'll try to sort this out in ruby-rackup (the new source package).

And about the warnings, I do not see most of them in the new version I am preparing right now, so I think they are already sorted out. The only one I see is the one related to the substvars but it says ${shlibs:Depends} is not defined but it actually is. I have seen this warning in multiple packages without a reason.

And finally, I see you comparing ruby-rack with rails, those are completely different things. Rails is a web framework as you mentioned and ruby-rack is just a middleware implementation which is also used by rails (rails depends on ruby-rack). In the broad pcs context, we are proposing the promotion of ruby-sinatra which is a web framework and it could be compared in some aspects with rails. I hope this clarifies things here.

I uploaded ruby-rack version 3.0.0-1 to experimental:

https://tracker.debian.org/news/1383207/accepted-ruby-rack-300-1-source-into-experimental/

Also packaged 2 new source packages containing the gems extracted from previous versions of ruby-rack:

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1023708
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1023761

Those 2 packages are in Debian NEW and requires ftp-master review, as you may know it might take some time. Moreover, the ruby team is concerned with all the breakages it might cause.

src:thin which is also one of the pcs dependencies we are aiming to promote depends on ruby-rack << 3, I filed an upstream bug asking for rack 3 support but we would need to provide a patch ourselves to get this fixed:

https://github.com/macournoyer/thin/issues/389

Due to all that, I'd like to ask to keep going with the promotion with the current ruby-rack version 2 while I try to move all the pieces to upgrade ruby-rack to version 3 which will likely take some time.

Upgrading rack to 3 would be nice for security.

https://github.com/rack/rack/commit/a5762cf60af474b89b555ff8d151be5a021701f8 removes deprecated authentication methods, but likely breaks legacy support in thin.

I reviewed ruby-rack 2.2.4-2 as checked into kinetic. This shouldn't be considered a full audit but rather a quick gauge of maintainability.

> Rack provides a minimal, modular, and adaptable interface for developing web applications in Ruby. By wrapping HTTP requests and responses in the simplest way possible, it unifies and distills the bridge between web servers, web frameworks, and web application into a single method call.

Rack 3.x is released, but many Ruby packages that depend on Rack have not migrated to 3.x. This security review considers the maintainability of Rack 2.x in the short-term and Rack 3.x maintainability in the long-term support. Security issues that are solved by Rack 3.x were not evaluated critically (see MD5 digest). The Security Team recommends against promoting Rack 2.x to main in a LTS release of Ubuntu (i.e., 24.04).

See 3.0.0.beta1's changelog: https://github.com/rack/rack/blob/main/CHANGELOG.md

- CVE History:
  - CVE-2011-5036, CVE-2012-6109, CVE-2013-0183, CVE-2013-0184, CVE-2013-0262, CVE-2013-0263, CVE-2015-3225, CVE-2018-16470, CVE-2018-16471, CVE-2019-16782, CVE-2020-8161, CVE-2020-8184, CVE-2022-30122, CVE-2022-30123
  - past CVEs relate to hash collisions, environmental variables, crypto timing attacks, regex, DoS (via specially crafted strings, packets, parameter calls), XSS, session hijacking, cookie validation, directory traversal, and shell escapes
  - see also https://github.com/rubysec/ruby-advisory-db/tree/master/gems/rack
  - recent CVEs are mentioned in CHANGELOG.md
  - recent commit fixes include CVE numbers
  - some CVEs also assigned GHSA numbers
  - ruby-rack security patches are made for multiple affected versions
    - hopefully upstream will support 2.x security patches
  - ruby-rack's github issue tracker is well maintained
  - ruby-rack has a robust Security Policy https://github.com/rack/rack/security/policy
- Build-Depends?
  - d/control requires gem2deb, rake, ruby-bacon, ruby-concurrent, ruby-dalli, ruby-minitest-global-expectations, ruby-webrick, thin
  - ruby-bacon is no longer being developed (see GH issue #32)
  - ruby-bacon and ruby-concurrent does not appear to be used by Rack
  - ruby-concurrent and ruby-webrick have open security issues on GitHub
  - thin dependency and handler were removed from rack 3.x
  - d/control needs to be cleaned up (deprecated depends, add Gemfile optional depends)
  - MIRs are missing for some dependencies
- pre/post inst/rm scripts?
  - none
- init scripts?
  - none
- systemd units?
  - none
- dbus services?
  - none
- setuid binaries?
  - none
- binaries in PATH?
  - /usr/bin/rackup
- sudo fragments?
  - none
- polkit files?
  - none
- udev rules?
  - none
- unit tests / autopkgtests?
  - d/ruby-tests.rake runs upstream's unit tests
  - contains simple autopkgtests
- cron jobs?
  - none
- Build logs:
  - nothing significant

- Processes spawned?
  - evals either removed in 3.x or non-user defined
    - see Rubocop section below
- Memory management?
  - ruby-dalli library provides memcached
    - removed in 3.x
  - ruby-concurrency has open GitHub issues for memory leaks
    - this d/controls build dependency does not appear to be used by Rake
-...

ruby-rack in jammy and older are affected by CVE-2022-30122 and CVE-2022-30123

Please note that the follow ruby-rack build dependencies are not in lunar main and do not have an open MIR: (1) gem2deb, (2) ruby-bacon, (3) ruby-concurrent, (4) ruby-dalli, and (5) ruby-minitest-global-expectations

edit: these dependencies are only required for build and do not require an MIR

On Sat, Jan 21, 2023 at 12:25 AM Mark Esler <email address hidden> wrote:
>
> Please note that the follow ruby-rack build dependencies are not in
> lunar main and do not have an open MIR: (1) gem2deb, (2) ruby-bacon, (3)
> ruby-concurrent, (4) ruby-dalli, and (5) ruby-minitest-global-
> expectations

That is fine as since Trusty only runtime dependencies are required.

Showing up in component mismatch now as planned.

Promoted together with the full PCS stack, details see https://bugs.launchpad.net/ubuntu/+source/pcs/+bug/1953341/comments/13