Session credentials backed by certificates or executables are now refused with named reasons.
What's wrong with this entry?
The credential payload used to start a session is now validated more strictly. It follows a bounded chain of nested credential sources and refuses X.509 certificate and executable-backed sources outright, with named failure reasons instead of generic errors. Always on.
- Named verdicts: secret_did_not_decode, unsupported_version, missing_session_ingress_token, missing_api_base_url.
- Failures now carry a dedicated shape-error type rather than an untyped throw.
an X.509 certificate credential source cannot be excluded from the shell
Strings lifted out of the shipped bundle, so the claim above can be checked against them.
Related
Other releases about the same thing. Found by shared names or similar wording; neither means one caused the other.
-
v2.1.224
Invalid sandbox credential settings now fail closed instead of being ignored
Both mention credential
-
v2.1.236
Credentials file reads reject symlinks and oversized files
Both mention credential
-
v2.1.239
PowerShell profiles and hardware SSH keys now count as sensitive files
Both mention credential