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
- File IO?
  - "Rack::Files for serving static files."
  - "Rack::Sendfile for working with web servers that can use optimized file serving for file system paths."
  - file IO in handlers fastcgi and webrick
    - handlers removed in Rack 3.x
  - generator.rb sendfile.rb, and server.rb appear solid
    - Rack 3.x removes two of three File.open commands
  - nb: files are opened with File.open() and not open()
- Logging?
  - operators have the abilitiy to tune their logging level
  - many components have --debug, --warn, and --quiet logging flags
  - logging specific middleware:
    - "Rack::CommonLogger for creating Apache-style logfiles."
    - "Rack::Logger for setting a logger to handle logging errors."
    - "Rack::ShowException for catching unhandled exceptions and presenting them in a nice and helpful way with clickable backtrace."
    - Rack::Events allow adding custom event logging
- Environment variable usage?
  - in Rack 2.x, ENV['x'] loads the environmental variables: HTTPS, RACK_ENV, RACK_HANDLER, and RACK_MULTIPART_PART_LIMIT
  - in Rack 3.x, only RACK_MULTIPART_PART_LIMIT is loaded
    - if set, converted to integer
- Use of privileged functions?
  - rewindable_input.rb chmods a temp file to 0000 in an attempt to limit access
    - there appears to be a race condition exploit between file creation and chmod
    - setting permisions on creation or umasking before creation patches this
      - see Tempfile.new()
    - attack vector is limited, as file initialized with default mode, 0600
- Use of cryptography / random number sources etc?
  - cookie.rb uses Ruby's openssl library
    - cookie.rb removed in Rack 3.x
      - moved to https://github.com/rack/rack-session (see also rack-contrib)
  - Rack::Auth::Digest::MD5 implements RFC 2617 which has been deprecated for being highly insecure
    - this and other insecure methods removed in Rack 3.x
- Use of temp files?
  - "Rack::TempfileReaper for removing temporary files creating during a request."
  - temp files appear to be defensively created
- Use of networking?
  - heavy use
  - dependencies ruby-webrick and thin are web server libraries
- Use of WebKit?
  - none
- Use of PolicyKit?
  - none

- Any significant cppcheck results?
  - none
- Any significant Coverity results?
  - none
- Any significant shellcheck results?
  - none
- Any significant bandit results?
  - none
- Any significant rubocop results?
  - eval in builder.rb
    - Rack::Builder.new_from_string only evaluates rackup configuration files (ie., not controlled by users)
    - see https://shime.sh/deep-dive/rackup
  - eval in server.rb
    - appears to only eval builder scripts
    - server.rb removed in Rack 3.x refactor
    - server.rb moved to https://github.com/rack/rackup
  - Marshal.load in cookie.rb
    - if an attacker can control cookie they can run remote code execution
    - this is only the case when "secure"/secrets/HMAC is not in effect
    - "Potential danger ahead! Marshal without verification and/or encryption could present a major security issue."
    - "This will not be supported in future versions of Rack, and future versions will even invalidate your existing user cookies."
    - cookie.rb removed in Rack 3.x refactor

d/controls needs clean up

Rack's `.rubocop.yml` disables Security checks.

This codebase is organized well. Code is commented exceptionally well. Maintainers are active. Rack 3.x solves security issues.

ruby-rack 3.x migrations will likely require a MIR for https://github.com/rack/rackup and https://github.com/rack/rack-session

This review does not ACK or NACK the promotion of ruby-rack build dependencies to main.

The Security Team recommends against including ruby-rack 2.x to main of an LTS release.

Security Team ACK for promoting ruby-rack to main.