On 11.02.23 22:54, Mark Dilger wrote:
Thanks Peter. Here are some observations about the documentation in patch
version 15.
In acronyms.sgml, the CEK and CMK entries should link to documentation, perhaps
linkend="glossary-column-encryption-key" and linkend="glossary-column-master-key". These
glossary entries should in turn link to linkend="ddl-column-encryption".
In ddl.sgml, the sentence "forcing encryption of certain parameters in the client library (see
its documentation)" should link to linkend="libpq-connect-column-encryption".
Did you intend the use of "transparent data encryption" (rather than "transparent
column encryption") in datatype.sgml? If so, what's the difference?
There are all addressed in the v16 patch I just posted.
Is this feature intended to be available from ecpg? If so, can we maybe
include an example in 36.3.4. Prepared Statements showing how to pass the
encrypted values securely. If not, can we include verbiage about that
limitation, so folks don't waste time trying to figure out how to do it?
It should "just work". I will give this a try sometime, but I don't see
why it wouldn't work.
The documentation for pg_dump (and pg_dumpall) now includes a
--decrypt-encrypted-columns option, which I suppose requires cmklookup to first
be configured, and for PGCMKLOOKUP to be exported. There isn't anything in the
pg_dump docs about this, though, so maybe a link to section 5.5.3 with a
warning about not running pg_dump this way on the database server itself?
Also addressed in v16.
How does a psql user mark a parameter as having forced encryption? A libpq user can
specify this in the paramFormats array, but I don't see any syntax for doing this from
psql. None of the perl tap tests you've included appear to do this (except indirectly
when calling test_client); grep'ing for the libpq error message "parameter with
forced encryption is not to be encrypted" in the tests has no matches. Is it just
not possible? I thought you'd mentioned some syntax for this when we spoke in person,
but I don't see it now.
This has been asked about before. We just need to come up with a syntax
for it. The issue is contained inside psql.
