On Thu, Sep 5, 2024 at 9:36 AM Jelte Fennema-Nio <postgres@jeltef.nl> wrote:
> 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).
Yeah, I figured it wasn't a quick fix.
> 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.
As long as the new thread doesn't also stall out/get forgotten, I'm happy.
> 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?
If we go that direction, I'd still like to know which platforms we
expect to have a suboptimal port, if for no other reason than
documenting that those users should try to get OpenSSL into their
builds. (I agree that they probably will already, if they care.)
And if I'm being really picky, I'm not sure we should call our port
"timingsafe_bcmp" (vs. pg_secure_bcmp or something) if we know it's
not actually timing-safe for some. But I won't die on that hill.
Thanks,
--Jacob
