[Security] Bump puma from 4.3.7 to 4.3.8

[dependabot-preview[bot]]

Bumps puma from 4.3.7 to 4.3.8. This update includes a security fix.

Vulnerabilities fixed

Sourced from The GitHub Security Advisory Database.

Keepalive Connections Causing Denial Of Service in puma This vulnerability is related to CVE-2019-16770.

Impact

The fix for CVE-2019-16770 was incomplete. The original fix only protected existing connections that had already been accepted from having their requests starved by greedy persistent-connections saturating all threads in the same process. However, new connections may still be starved by greedy persistent-connections saturating all threads in all processes in the cluster.

A puma server which received more concurrent keep-alive connections than the server had threads in its threadpool would service only a subset of connections, denying service to the unserved connections.

Patches

This problem has been fixed in puma 4.3.8 and 5.3.1.

Workarounds

Setting queue_requests false also fixes the issue. This is not advised when using puma without a reverse proxy, such as nginx or apache, because you will open yourself to slow client attacks (e.g. slowloris).

The fix is very small. A git patch is available here for those using unsupported versions of Puma.

For more information

... (truncated)

Affected versions: <= 4.3.7

Release notes

Sourced from puma's releases.

v4.3.8

• Security
  • Close keepalive connections after the maximum number of fast inlined requests (#2625)

Changelog

Sourced from puma's changelog.

4.3.8 / 2021-05-11

• Security
  • Close keepalive connections after the maximum number of fast inlined requests (#2625)

Commits

• b911c13 4.3.8 release note
• 09bb777 Bump version constant
• 8088950 Close keepalive connections after MAX_FAST_INLINE requests
• See full diff in compare view

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.

---

Dependabot commands and options

You can trigger Dependabot actions by commenting on this PR:

• @dependabot rebase will rebase this PR
• @dependabot recreate will recreate this PR, overwriting any edits that have been made to it
• @dependabot merge will merge this PR after your CI passes on it
• @dependabot squash and merge will squash and merge this PR after your CI passes on it
• @dependabot cancel merge will cancel a previously requested merge and block automerging
• @dependabot reopen will reopen this PR if it is closed
• @dependabot close will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually
• @dependabot ignore this major version will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)
• @dependabot ignore this minor version will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)
• @dependabot ignore this dependency will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)
• @dependabot use these labels will set the current labels as the default for future PRs for this repo and language
• @dependabot use these reviewers will set the current reviewers as the default for future PRs for this repo and language
• @dependabot use these assignees will set the current assignees as the default for future PRs for this repo and language
• @dependabot use this milestone will set the current milestone as the default for future PRs for this repo and language
• @dependabot badge me will comment on this PR with code to add a "Dependabot enabled" badge to your readme

Additionally, you can set the following in your Dependabot dashboard:

• Update frequency (including time of day and day of week)
• Pull request limits (per update run and/or open at any time)
• Automerge options (never/patch/minor, and dev/runtime dependencies)
• Out-of-range updates (receive only lockfile updates, if desired)
• Security updates (receive only security updates, if desired)

[RachelWyatt]

Hi @maebeale, is this for /user_management (screenshot below)?

If so, a couple of questions:

1. The screenshotted page is in the code as a show page but I think is really acting as more of an index page. Is there any sense in refactoring that? Is there potential need for a show page for user management? Or would that just end up being /users/show? 1a. Another option -- should this page be moved to users/index? Right now it doesn't look like User Management has any special functionality, but I didn't know if that was a plan for the future.
2. Should the edit page the button links to be at /user_management/1/edit or /users/1/edit?

Or if I'm looking at the totally wrong path just let me know :)

[RachelWyatt]

For this PR I'm:

• Adding users_management/editpage and route to allow a user with the MANAGE_USERS permission to edit other users' permissions. User with MANAGE_USERS permission should be able to add or delete all permissions for each user.
• This will not be the place for editing a User's name, e-mail, etc., or deleting a user. That functionality should live in Users and User_management should be just for handling permissions.