This is a follow up to [CVE-2022-23633].

Add support for YubiKey OTP codes during release

Under certain circumstances, the middleware isn't informed that the
response body has been fully closed which result in request state not
being fully reset before the next request.

[CVE-2022-23633]

* 5-2-sec:
  Preparing for 5.2.4.6 release
  Update changelog
  Prevent slow regex when parsing host authorization header
  Prevent string polymorphic route arguments

The old regex could take too long when parsing an authorization header,
and this could potentially cause a DoS vulnerability

[CVE-2021-22904]

url_for supports building polymorphic URLs via an array
of arguments (usually symbols and records). If an array is passed,
strings can result in unwanted route helper calls.

CVE-2021-22885

[5-2-stable] Backport Upgrade-safe URL-safe CSRF tokens #39076

[6-0-stable] Backport Upgrade-safe URL-safe CSRF tokens #39076

The compatibility issue #41783 is caused by 08edf165 and abd27d51 to fix
the wrong number of arguments error which is caused by d124f192 (Ruby 2.2
doesn't have `Base64.urlsafe_encode64(..., padding: false)` option).

https://buildkite.com/rails/rails/builds/69289#5fba2577-5872-446a-af47-27c188850924/911-919

When I was fixing this error, I accidentally introduced a part of #18496
to 5-2-stable because I referred to the code in the master branch, and
the new error occurred.

https://buildkite.com/rails/rails/builds/69290#95836b97-b446-4d41-a3a5-a1da2149bad3/911-1095

In that time, I wasn't sure why the new error occurred. Since I supposed
the master branch is correct, I fixed the failure tests one by one,
referred to the test code in the master branch. As a result, #18496 was
introduced to 5-2-stable without cf3736dc.

I've reverted 08edf165 and abd27d51 since the incompatible change was
unintentional, and I've made correct fix for the wrong number of
arguments error.

This reverts commit 08edf165.

This reverts commit abd27d51.

[ci skip] Clarify 5.2.4.1 Changelog entry

It seems that the changes in 5.2.4.1 have led to a number of discussions on commits, issues and pull requests. Clarifying the Changelog entry seems like the most direct way to help people apply the security patch smoothly.

Carefully crafted input can cause a DoS via the regular expressions used
for validating the money format in the PostgreSQL adapter.  This patch
fixes the regexp.

Thanks to @dee-see from Hackerone for this patch!

[CVE-2021-22880]

https://buildkite.com/rails/rails/builds/71913#bc3011fb-51cd-4037-bbaf-45ef91d3786a/914-931

When a PDF is used for both printing and displaying. It will most likely
contain a crop box in order to hide print margins when displaying the PDF.

Use Poppler's parameter to automatically use the crop box (visible box)
rather than the media box (printable box) in order to remove those margins
when drawing the PDF.

See https://manpages.debian.org/testing/poppler-utils/pdftoppm.1.en.html

Prior to this commit, when a translation key indicated that the
translation text was HTML, the value returned by `I18n.translate` would
always be marked as `html_safe`.  However, the value returned by
`I18n.translate` could be an untrusted value directly from
`options[:default]`.

This commit ensures values directly from `options[:default]` are not
marked as `html_safe`.

Co-authored-by: Jonathan Hefner <jonathan@hefner.pro>

Prior to this commit, when a translation key indicated that the
translation text was HTML, the value returned by `I18n.translate` would
always be marked as `html_safe`.  However, the value returned by
`I18n.translate` could be an untrusted value directly from
`options[:default]`.

This commit ensures values directly from `options[:default]` are not
marked as `html_safe`.

Co-authored-by: Jonathan Hefner <jonathan@hefner.pro>

Prior to this commit, when a translation key indicated that the
translation text was HTML, the value returned by `I18n.translate` would
always be marked as `html_safe`.  However, the value returned by
`I18n.translate` could be an untrusted value directly from
`options[:default]`.

This commit ensures values directly from `options[:default]` are not
marked as `html_safe`.

Co-authored-by: Jonathan Hefner <jonathan@hefner.pro>

Prior to this commit, when a translation key indicated that the
translation text was HTML, the value returned by `I18n.translate` would
always be marked as `html_safe`.  However, the value returned by
`I18n.translate` could be an untrusted value directly from
`options[:default]`.

This commit ensures values directly from `options[:default]` are not
marked as `html_safe`.

This is a backport of updates made to [master](https://github.com/rails/rails/pull/35096).

In order to set custom options (e.g. a custom domain name) on the azure storage client, the ActiveStorage adapter must allow more options to be passed to the initializer. Currently `ActiveStorage::Service::AzureStorage` only allows for a fixed set of options.

Here we add the ability to pass additional options to the initializer.

Update aws-sdk-s3 dependency

That test requires Marshal is prepended by `MarshalWithAutoloading`.

Rack updated the RFC they're adhering to when parsing cookies, now no
longer including commas.

There's still an open question as mentioned in:
https://github.com/rails/rails/issues/38420

However, the resilience test is no longer as well needed as it once was
and we can move forward separately. If not, this is easily revertible.

Fix wrong spec asserting headers maintain original definition