rack
Update webrick version to 1.8.2
Updates the pinned version of webrick to 1.8.2, since a CVE impacts earlier versions: https://nvd.nist.gov/vuln/detail/CVE-2024-47220
This change should not be landed as not only does the current constraint allow for the patched version of webrick, ~> pins to the last version group which is currently minor but by adding a patch version it would become patch.
i.e. the current constraint allows for >= 1.8.0 <2.0.0 whereas the proposed new constraint only allows >= 1.8.0 <1.9.0 which is tighter.
Ideally it'd be better to just remove the dependency all together as apparently it's not directly needed
tl;dr the correct specification should be
spec.add_dependency "webrick", "~> 1.8", ">= 1.8.2"
fixing it here (and pushing it) does not preclude doing https://github.com/rack/rackup/issues/12.
... but it does help from a vulnerability report standpoint 😅
This PR, even if corrected, is unnecessary, a CVE in webrick does not make rackup stop working with it. Just do bundle lock --update=webrick and restrictivly pin in your own gemfile if necessary.
does not make rackup stop working with it.
What does that mean? 😅
restrictivly pin in your own gemfile if necessary
Pinning a transitive dependency means requiring it. ... even if the gem is unnecessary for us too (i.e., agreeing on https://github.com/rack/rackup/issues/12). So if I pin it now, but you go forward with https://github.com/rack/rackup/issues/12, it means I'll need to manually re-remove it then.
Nominally fixing this, albeit arbitrary, is still a pure-positive step forward (at the cost of one PR/commit).
What does that mean?
It is not the job of a dependency to ensure you are getting only cve-free gems.
Pinning a transitive dependency means requiring it.
You can do gem "webrick", "~> whatever", require: false and that doesn't happen. In this case it doesn't really matter since rackup already unconditionally requires webrick anyways.
Nominally fixing this, albeit arbitrary, is still a pure-positive step forward (at the cost of one PR/commit).
Also, it's actually not pure positive since a new version needs to be released so:
- this requires time from the person making the pull request (and us all to bikeshed it)
- this requires time from the maintainer to merge and release the new version
- this requires time from the consumer to update to that new version
... and if the consumer is updating rackup, they're doing the same amount of work as they would to update webrick itself - so this is in fact more work than "just update webrick" and arguably pure-negative
(if you really wanted to pile on, you could also argue this requires time from the security team that has to audit the new version of rackup in addition to the new version of webrick as part of their ISO27001 or SOC2 or ABC123-whatever enterprise requirements)