On Thu, 5 Sept 2024 at 17:43, Jacob Champion
<jacob.champion@enterprisedb.com> wrote:
> Has there been any work/discussion around not sending the cancel key
> in plaintext from psql? It's not a prerequisite or anything (the
> longer length is a clear improvement either way), but it seems odd
> that this longer "secret" is still just going to be exposed on the
> wire when you press Ctrl+C.
Totally agreed that it would be good to update psql to use the new
much more secure libpq function introduced in PG17[1]. This is not a
trivial change though because it requires refactoring the way we
handle signals (which is why I didn't do it as part of introducing
these new APIs). I had hoped that the work in [2] would either do that
or at least make it a lot easier, but that thread seems to have
stalled. So +1 for doing this, but I think it's a totally separate
change and so should be discussed on a separate thread.
[1]: https://www.postgresql.org/docs/17/libpq-cancel.html#LIBPQ-CANCEL-FUNCTIONS
[2]:
https://www.postgresql.org/message-id/flat/20240331222502.03b5354bc6356bc5c388919d%40sraoss.co.jp#1450c8fee45408acaa5b5a1b9a6f70fc
> For the cancel key implementation in particular, I agree with you that
> it's probably not a serious problem. But if other security code starts
> using timingsafe_bcmp() then it might be something to be concerned
> about. Are there any platform/architecture combos that don't provide a
> native timingsafe_bcmp() *and* need a DIT bit for safety?
It sounds to me like we should at least use OpenSSL's CRYPTO_memcmp if
we linked against it and the OS doesn't provide a timingsafe_bcmp.
Would that remove your concerns? I expect anyone that cares about
security to link against some TLS library. That way our "fallback"
implementation is only used on the rare systems where that's not the
case.
