Not sure if this needs an upgrade path?

^^ I think we're going to need some kind of config.action_dispatch option here in an initializer (with the newer algorithm as the default in new apps), not sure if this could possibly break some existing apps 😬

Needs an upgrade path. It'd break all existing browser sessions when an app upgrades Rails versions.

This would be much simpler if we offered a way to rotate message verifiers. Read with new verifier and fall back to old verifier (possibly with a different key or digest or …); write with new verifier.

@jeremy something like cookies hybrid serializer preparing way for json that we had in 4.1?

Cool, we need to get #18772 in. Let me do a recreation on that.

message_encryptor.rb line 43 still mentions SHA1 as the default in this PR.

While we're changing defaults: it seems it is better to switch to an AEAD mode such as aes-256-gcm as well and remove the manual signing with MessageVerifier. Right now users can use the same key for both encryption as authentication, while not unsafe it isn't regarded as the best thing to do either. It is also faster than aes-256-cbc + hmac-sha1. GCM support was added in OpenSSL 1.0.1, released 14 March 2012 so it should be widely supported now.

https://github.com/rails/rails/pull/28132/files

Just want to point out that it is now possible to rotate from SHA1 signed cookies to SHA256 (or SHA512 for that matter). This was brought in my #29716. Please refer to the Security guide for more details: https://github.com/rails/rails/blob/04a7b7165ad204014c5850f62c921f7291d6ba5d/guides/source/security.md#rotating-encrypted-and-signed-cookies-configurations