On Tue, Jul 07, 2009 at 05:35:28PM +0900, Itagaki Takahiro wrote:
> Our manual says we can use pgcrypto functions or encrypted filesystems
> for data encryption.
> http://www.postgresql.org/docs/8.4/static/encryption-options.html
>
> However, they are not always the best approaches in some cases.
>
> For pgcrypto functions, user's SQL must contain keyword strings
> and they need to consider which column is encrypted. Users complaint
> that that they want to treat encrypted values as if not-encrypted.
As others have said, handling encryption client side would seem to offer
many more benefits (transparently within libpq offering easy adoption).
> passward() and options() are SQL functions and we can re-define them
> if needed. The default implementations are to refer custom GUC variables
> (pgcrypto.password and pgcrypto.options) so that encryption are done
> only in database server and applications don't have to know the details.
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. You wouldn't even need to be a super-user to collect all
the passwords otherwise, just create a function that has the name of
something common and have it stash the password aware somewhere.
-- Sam http://samason.me.uk/