Sam Mason <s...@samason.me.uk> wrote: > As others have said, handling encryption client side would seem to offer > many more benefits (transparently within libpq offering easy adoption).
Libpq is not the only driver. Do we need to develop transparent decryption for each drivers? (libpq, JDBC, npgsql, py-postgresql, ...) Also, if you disallow server-side decode, you cannot create indexes on encrypted values because the same values are not always encrypted to the same codes. (Indexes will sort keys based on order of decoded values.) I think there is no difference between client-side decryption and clinet-supplied password as far as clinet-server communication is encrypted (i.e, SSL login). > Should the password be this widely shared? it would seem to make more > sense if it was a write-only variable and never exposed outside the > crypto module. We can use an user-defined GUC variables as a write-only variable. When we supply some show_hook function to GUC variable, SET still works but SHOW only shows '****' and hides real passwords. Regards, --- ITAGAKI Takahiro NTT Open Source Software Center -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
