{"id":15006,"date":"2026-10-26T07:00:00","date_gmt":"2026-10-26T12:00:00","guid":{"rendered":"https:\/\/www.allerin.com\/blog\/?p=15006"},"modified":"2026-10-24T10:22:40","modified_gmt":"2026-10-24T15:22:40","slug":"rails-readers-secrets-23-october-2026","status":"publish","type":"post","link":"https:\/\/www.allerin.com\/blog\/rails-readers-secrets-23-october-2026\/","title":{"rendered":"Rails tightens readers and secrets, 23 October 2026"},"content":{"rendered":"
\n

On 26 October 2026, Rails 8.0 is 12 calendar days from the security-support deadline currently published as 7 November<\/a>. The 23 October Rails weekly<\/a> gives an application team three checks worth carrying into its upgrade work: which old messages it accepts, who can read its local signing secret, and what a SQLite column rename preserves.<\/p>\n

The changes below are on main<\/a>. They are absent from the checked released tags 8.1.4<\/a> and 8.0.5.1<\/a>. A merge is a reason to prepare a regression check, not a promise about a future release.<\/p>\n

JSON writers can still have Marshal readers<\/h2>\n

PR #59156<\/a> makes config.load_defaults 8.2<\/code> select :json<\/code> for Active Support messages. Applications retaining defaults from 7.1 through 8.1 continue to select :json_allow_marshal<\/code>. An explicit serializer or rotation also needs its own inspection.<\/p>\n

Rails 7.1, released in 2023<\/a>, adopted JSON message writing while retaining a Marshal reader. The original change<\/a> protected existing signed and encrypted messages during upgrades. That compatibility reader outlived the proposed transition. A JSON writer therefore does not prove that old Marshal messages have stopped arriving.<\/p>\n

This benign fixture makes the distinction visible. It ran against Active Support 8.1.4 and the pinned main source with Ruby 3.4.10, with the same output on both. The key and message exist only inside the example.<\/p>\n

require \"active_support\"\r\nrequire \"active_support\/message_verifier\"\r\n\r\nkey = \"synthetic-only-key\" * 4\r\nold = ActiveSupport::MessageVerifier.new(key, serializer: :marshal)\r\ntoken = old.generate({ \"example\" => 1 })\r\n[:json_allow_marshal, :json].each do |format|\r\n  reader = ActiveSupport::MessageVerifier.new(key, serializer: format)\r\n  begin\r\n    puts \"#{format}: accepts old message = #{!reader.verified(token).nil?}\"\r\n  rescue RuntimeError => error\r\n    raise unless error.message == \"Unsupported serialization format\"\r\n    puts \"#{format}: rejected (#{error.message})\"\r\n  end\r\nend\r\n<\/code><\/pre>\n
json_allow_marshal: accepts old message = true\r\njson: rejected (Unsupported serialization format)\r\n<\/code><\/pre>\n
For an application already on 7.1 or later, observe message_serializer_fallback.active_support<\/code> before choosing :json<\/code>. Account for long-lived tokens and rollback readers; a quiet observation period is evidence only for the traffic it covers. Applications still on 5.2 or 6.1 need the intervening upgrade and format transition first. The existing Marshal audit checklist<\/a> follows cookies, caches and columns separately. This week’s message default does not retire those other readers.<\/p>\n
A local secret needs local protection<\/h2>\n
PR #59247<\/a> creates tmp\/local_secret.txt<\/code> with mode 0600<\/code>. On non-Windows platforms it also attempts to tighten an existing file’s permissions while retaining its contents. Failure to change permissions is tolerated, so inspect the actual file rather than assuming startup repaired it.<\/p>\n
Rails 7.1 in 2023 renamed<\/a> development_secret.txt<\/code> to local_secret.txt<\/code> because development and test both used it. The tagged implementation<\/a> persists the generated key between runs. The new patch changes who can read that file without changing the key.<\/p>\n
In a temporary-directory check under umask 022<\/code>, the released 8.1.4 generation method produced 0644<\/code>; main produced 0600<\/code>. Main also tightened an existing 0644<\/code> fixture and preserved its contents. These are macOS file-mode observations, not Windows ACL tests. Review local workspaces and SECRET_KEY_BASE_DUMMY<\/code> build paths. Production applications using an explicit secret are outside this file change, and tighter permissions cannot revoke a secret already disclosed.<\/p>\n
A SQLite rename should preserve the schema around it<\/h2>\n
PR #59204<\/a> replaces table rebuilding with SQLite’s native column rename. Rails 5.2 in 2018<\/a> already rebuilt tables for this operation<\/a>, accommodating SQLite’s earlier limited alteration support. SQLite 3.25.0 added column renaming in September 2018<\/a>.<\/p>\n
A disposable SQLite check exposed more than a migration exception. On Rails 8.1.4, renaming a column used by a partial index failed. A separate rename silently dropped a trigger, and renaming a string primary key lost its primary-key declaration. On pinned main, the index rename succeeded, the trigger survived and executed, and the renamed primary key remained. Both runs used SQLite 3.53.2 through sqlite3 2.9.6, so the Rails adapter choice caused the difference.<\/p>\n
For a SQLite application, rehearse the migration against a schema containing its dependent objects and check those objects afterward. A successful migration alone would have missed the dropped trigger. PostgreSQL and MySQL applications have no action for this SQLite-specific patch.<\/p>\n
What to do this week<\/h2>\n