Repository navigation
Conversation
Allow a mixed-version pool to keep writing SHA-256-derived internal JWEs while upgraded nodes accept both legacy and PBKDF2-derived encryption. After all old nodes are drained, operators can disable legacy writes, restart, and retain legacy reads until old values expire or are replaced. Isolate temporary key selection, read fallback, and post-validation session rewrites in jwt_compat hooks. Cover session cookies, login-state cookies, and encrypted cache values. Both configuration controls default to Off. Validate the staged rollout, old-key interoperability, configuration inheritance, invalid input rejection, and hook persistence failures.
Return NULL when both normal and compatibility verification fail. Preserve short-circuit fallback while making the verification boundary explicit and avoiding CI's -Werror=unused-value failure.
|
The build failure came from discarding the result of the standalone The proposed fix uses an early-return guard: if both verification paths fail, return Previously, failed verification left the payload Alternatives:
|
|
Thanks for the work on this, and for the careful write-up and tests. I'm going to close this as won't-fix. The key derivation change shipped in 2.4.20 on 2026-08-01, and every 2.4.20.x release since has opened its notes with the same warning: sessions created by 2.4.19.x and earlier are invalid after the upgrade. Deployments have had two and a half months and four releases to cross that boundary, and the one-time re-login is the documented cost. Adding two directives and a compatibility layer now would serve a shrinking set of deployments, and would keep the unstretched SHA-256 key path in the tree. The scope is also narrower than it looks: 2.4.19 changed the internal session format as well, so this would only bridge 2.4.19.x nodes, not anything older. For a mixed pool upgrading from 2.4.19.x today, the practical options are sticky sessions for the duration of the rollout, or accepting the one-time re-authentication. |
|
Understood. We have an estate that is wholly without sticky sessions, which
is automatically rebuilt and redeployed. Breaking sessions have caused us
issues in the past during the rolling upgrades. We have a cautious rollout
to help mitigate it but we still suffer from blips and the rollout itself
is incredibly painful.
I recently introduced tests into our environment to raise visibility on
session level changes in the hopes that we could increase our upgrade
speeds without increased risk, with my thought being, "hey. they haven't
changed it in years. Maybe we'll be ok. " Within a few days I was made
aware that the session was changing/changed. We've been holding the rollout
of the update because of the impact it causes us.
We'll try a sticky session rollout. I have my doubts but it's worth
exploring. Thanks for the suggestion.
…-Chris
On Thu, Oct 15, 2026, 09:31 Hans Zandbelt ***@***.***> wrote:
*zandbelt* left a comment (OpenIDC/mod_auth_openidc#1399)
<#1399 (comment)>
Thanks for the work on this, and for the careful write-up and tests.
I'm going to close this as won't-fix. The key derivation change shipped in
2.4.20 on 2026-08-01, and every 2.4.20.x release since has opened its notes
with the same warning: sessions created by 2.4.19.x and earlier are invalid
after the upgrade. Deployments have had two and a half months and four
releases to cross that boundary, and the one-time re-login is the
documented cost. Adding two directives and a compatibility layer now would
serve a shrinking set of deployments, and would keep the unstretched
SHA-256 key path in the tree.
The scope is also narrower than it looks: 2.4.19 changed the internal
session format as well, so this would only bridge 2.4.19.x nodes, not
anything older.
For a mixed pool upgrading from 2.4.19.x today, the practical options are
sticky sessions for the duration of the rollout, or accepting the one-time
re-authentication.
—
Reply to this email directly, view it on GitHub
<#1399?email_source=notifications&email_token=AAD4KCZEVP5OZLN5IFNBB4L5UDGRLA5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTMMJZGMZDOMBZGIYKM4TFMFZW63VGMF2XI2DPOKSWK5TFNZ2KYZTPN52GK4S7MNWGSY3L#issuecomment-6193270920>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAD4KC6GF3ALAA5PR257XGL5UDGRLAVCNFSNUABEKJSXA33TNF2G64TZHMYTQMJYG42TAOB3JFZXG5LFHM2TQNJZGIYTMNBZG2QXMAQ>
.
You are receiving this because you authored the thread.Message ID:
***@***.***>
|
The PBKDF2 change in 2.4.20 makes existing sessions unreadable even when
OIDCCryptoPassphraseis unchanged. During a rolling upgrade, immediately issuing PBKDF2-encrypted values also makes upgraded nodes' writes unreadable by old nodes.This adds two opt-in controls for internal session cookies, login-state cookies, and encrypted cache values:
OIDCCryptoLegacyReadOIDCCryptoLegacyWriteBoth default to Off. Startup rejects legacy writes without legacy reads. During the second phase, authenticated and validated legacy session cookies are rewritten with the current key without changing their payload, session identifier, or expiry. Other encrypted cache values remain readable and transition through normal writes or expiry.
Temporary behavior lives in
jwt_compat.c: an encryption-key hook, a failed-verification hook, and a post-validation persistence hook. The hooks check the configuration internally. The ordinary verifier stays unchanged, and the session layer supplies its private cookie writer as a callback. In a release without an encryption migration, the hooks can become no-ops without changing their callers.The migration requires the same passphrase and compatible payload schemas and compression settings across nodes. It does not bridge the separate 2.4.19 payload change. Do not reintroduce unpatched nodes after PBKDF2 writes begin; keep legacy reads enabled until all relevant session and cache lifetimes have elapsed. Legacy mode retains the original key-guessing exposure and is intended to be temporary.
Validation:
make -j2 check: 17 test targets pass, including 23 session tests and 29 configuration tests.Related: #1397
Opening as a draft to invite feedback on the hook API and rollout controls before treating this as ready to merge.