Not handling them can expose the original unencrypted value in
a runtime exception log entry (a crash report).
However, this decision comes with an important trade-off covered
below.
We treat timeouts the same way we do other "encrypting was not possible"
scenarios: return the original value. This won't be acceptable to every user
but might be to some. There is no right or wrong answer to whether
availability or security are more important, so the users have to decide
whether using {plaintext, Term} results is appropriate in their specific case.
If it's not then {plaintext, Term} responses should be treated as errors.
In RabbitMQ's specific case the risk is credential exposure in a very specific,
unlikely case, or reduced availability for client connections in the same case.
Not handling them can expose the original unencrypted value in a runtime exception log entry (a crash report).
However, this decision comes with an important trade-off covered below.
We treat timeouts the same way we do other "encrypting was not possible" scenarios: return the original value. This won't be acceptable to every user but might be to some. There is no right or wrong answer to whether availability or security are more important, so the users have to decide whether using {plaintext, Term} results is appropriate in their specific case. If it's not then
{plaintext, Term}responses should be treated as errors.In RabbitMQ's specific case the risk is credential exposure in a very specific, unlikely case, or reduced availability for client connections in the same case.