Summary
After hours of an active session, encrypted session slots (horde/auth_app/*, imap_ob_pass/*) become unreadable, causing "no credentials in session" errors (IMP) or LDAP bind failures with an empty password. The session itself remains marked as authenticated.
Observed on
- OIDC integration (horde-dev-02): tested with both
hkdf-only and hkdf-with-legacy-fallback key formats — bug present in both.
- LDAP auth, two separate instances (production-like and home) — same symptom.
Symptoms
drainEncrypted: drop slot horde/auth_app/imp: Invalid PKCS#7 padding byte: 0xB9
drainEncrypted: drop slot horde/auth_app/ingo: Invalid PKCS#7 padding byte: 0xB9
drainEncrypted: drop slot imp/imap_ob_pass/...: Inconsistent PKCS#7 padding bytes.
On LDAP:
Bind failed: Server is unwilling to perform
in /var/www/horde-git/horde/Ldap/lib/Horde/Ldap.php:244
slapd: unauthenticated bind (DN with no password) disallowed
The session stays authenticated, but the app-level credentials needed to actually connect (IMAP, LDAP) are gone.
Recovery
Killing the session (clearing cookies / deleting the session row) resolves the issue immediately. Logging out and back in without clearing the session sometimes works after many attempts, but is not reliable.
What I ruled out
I attempted a fix on Horde_Core_Secret_Cbc/SessionLifecycle::regenerate(): freezing the resolved key before drainEncrypted() and releasing it after refillEncrypted(), to prevent getKey() from silently minting a fresh key mid-drain if the session key slot were transiently absent.
This did not resolve the issue — the frozen key was confirmed non-empty (freezeKey: frozen key=ok) at the time of the failure, yet decryption still failed. This suggests the root cause is not (only) getKey() minting a fresh key mid-drain — the frozen key itself does not match the key that encrypted the data.
What I have not yet isolated
I don't have a reliable, minimal reproduction, and I have not yet identified the exact point where the key used to encrypt a slot diverges from the key later used to decrypt it. I'm opening this now to have the symptom on record, since the freeze attempt already rules out one plausible cause. I can gather more targeted logs (key/salt value at write time vs read time) if that would help narrow it down.
Summary
After hours of an active session, encrypted session slots (
horde/auth_app/*,imap_ob_pass/*) become unreadable, causing "no credentials in session" errors (IMP) or LDAP bind failures with an empty password. The session itself remains marked as authenticated.Observed on
hkdf-onlyandhkdf-with-legacy-fallbackkey formats — bug present in both.Symptoms
On LDAP:
The session stays authenticated, but the app-level credentials needed to actually connect (IMAP, LDAP) are gone.
Recovery
Killing the session (clearing cookies / deleting the session row) resolves the issue immediately. Logging out and back in without clearing the session sometimes works after many attempts, but is not reliable.
What I ruled out
I attempted a fix on
Horde_Core_Secret_Cbc/SessionLifecycle::regenerate(): freezing the resolved key beforedrainEncrypted()and releasing it afterrefillEncrypted(), to preventgetKey()from silently minting a fresh key mid-drain if the session key slot were transiently absent.This did not resolve the issue — the frozen key was confirmed non-empty (
freezeKey: frozen key=ok) at the time of the failure, yet decryption still failed. This suggests the root cause is not (only)getKey()minting a fresh key mid-drain — the frozen key itself does not match the key that encrypted the data.What I have not yet isolated
I don't have a reliable, minimal reproduction, and I have not yet identified the exact point where the key used to encrypt a slot diverges from the key later used to decrypt it. I'm opening this now to have the symptom on record, since the freeze attempt already rules out one plausible cause. I can gather more targeted logs (key/salt value at write time vs read time) if that would help narrow it down.