Change default KeyGenerator digest to SHA1 to fix cookies in rolling upgrades

[ClearlyClaire]

Follow-up to #25668

Rails 7 changed the default KeyGenerator digest algorithm from SHA1 to SHA256, thus breaking encrypted cookies.

The official Rails documentation suggests configuring encrypted cookie rotation from cookies using the SHA1 digest algorithm, which we did, and it covers a clean Rails 6 to Rails 7 update path.

However, larger Mastodon instances typically have multiple puma servers running, and performing a rolling update will almost surely make Rails 6 and Rails 7 code coexist for a few seconds or minutes, in which case a client might get served with Rails 7, upgrading the cookie from SHA1 to SHA256, then back to Rails 6, which won't be able to read the cookie.

This PR changes Rails' default digest back to SHA1 so generated encrypted cookies remain compatible with 4.1.4, allowing rolling upgrades where multiple versions of the code coexist for a short time, and sets cookie rotation to handle reading from cookies using the SHA256 digest, so that rolling upgrades to a later version switching to SHA256 are possible.

The idea is to change the digest back to Rails 7's default (SHA256) in 4.2.1 (and switch the rotation to handle SHA1 cookies).

cc @mjankowski

[mjankowski]

The way I understood this hash_digest_class argument is that it was essentially specifiying which algorithm the incoming cookies had been created with, which in our case for existing non-updated-to-rails-7 instances is SHA1 -- and it seems like this change would tell the rotator that the incoming cookies to be rotated were created with SHA256? Or do I misunderstand this setting?

[ClearlyClaire]

You are not misunderstanding, it tells Rails how to read existing cookies that use SHA256.

This is so the version with this PR can coexist with an upcoming that switches to outputting SHA256.

[mjankowski]

Ah, so is the rotator behavior then to just silently do nothing when it gets cookies created with any other digest than what is specified? I guess it would have to be, because once you rotate you don't want to keep rotating.

So in that case, just to think out loud a bit...

• The combination of leaving the default as SHA1 and putting in a rotator that only rotates SHA256, does seem like it would solve the "how can do rolling deploys to get rails-6 instances running rails-7 with minimal session disruption?". During the deploy, all prior cookies will be SHA1, they'll be read fine. Newly generated cookies will be SHA1 due to explicitly setting to the Digest::SHA1 class and not accepting rails 7 defaults; and the cookie rotator will just do nothing for now since there won't be any inbound SHA256-created cookies coming in.

Then on a subsequent release, if we flip off the digest_class setting (and thus the Rails 7 default of SHA256 takes effect), and also flip the rotator to look to rotate SHA1-created cookies, then during the rolling deploy:

• The first app servers flipped over will see some SHA1 cookies and use the rotator to flip them to their new setting of SHA256
• The last app servers flipped over MIGHT see some traffic from sessions that have already been flipped to SHA256, in which case they will flip them back to SHA1 (due to this PR).
• In theory a session could be flipped back and forth many times like this during the rolling deploy, depending how long it is, but it wouldn't matter because the cookies would keep getting read.
• Once the deploy is done and all app servers are on the R7 code and have the SHA256 default behavior and the cookie rotator, the flip flopping will stop and all cookies will slowly be rotated to SHA256 (over some number of weeks/months/etc -- whatever is decided as reasonable period)
• After that X duration, we can remove the rotator entirely, even at the cost of lossing session for anyone who hasn't visited for longer than the duration.

Is that roughly accurate and more in line with the intentions here?

[ClearlyClaire]

Yes!

[mjankowski]

Yes!

Ok, cool - I think that works.

Not sure how to test this ... ideally you could create like a 2-server mini cluster just running locally and have an http server flip inbound requests back and forth between them, and then just make a bunch of requests and watch that the format gets adjusted back and forth all while preserving session.

[ClearlyClaire]

I tested by reverting the Rails 7 update and it seems to work!