From: | Erik Aronesty <erik(at)q32(dot)com> |
---|---|
To: | Tomas Vondra <tomas(dot)vondra(at)2ndquadrant(dot)com> |
Cc: | pgsql-general(at)postgresql(dot)org |
Subject: | Re: pgcrypto question |
Date: | 2019-10-07 20:39:07 |
Message-ID: | CAJowKgJubfVEAkM2aMfo7+gmL_ZCypbUE+AxN2eN3RwtTR6AKg@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
Actually I found a nice open source product "Acra" ... seems to do
the whole thing via a proxy. Now I need to see if I can customize the
encryption enough using a plugin (but at least I can fork it and start
from there). A proxy encryption system seems to be the right call,
then all my client apps can stay the same.
On Mon, Oct 7, 2019 at 3:49 PM Tomas Vondra
<tomas(dot)vondra(at)2ndquadrant(dot)com> wrote:
>
> On Mon, Oct 07, 2019 at 02:51:30PM -0400, Erik Aronesty wrote:
> >Good idea for "psycopg". It would be easy for a POC, but I think the
> >only meaningful layer to operate at would be a libpq drop-in
> >replacement that intercepts PQgetvalue, PQprepare, PQexecParams,
> >PQexecPrepared ... etc. That way odbc, python, node, etc would "just
> >work".... as long as you used LD_PRELOAD appropriately.
> >
>
> It's not clear to me how would that know which columns are encrypted,
> with what key, etc. Because those encrypted columns are essentially just
> regular bytea columns, so there's no easy way to distinguish them.
>
> I'm no psycopg2 expert, but it does have some infrastructure for casting
> PostgreSQL types to Python types, and I guess that could be used for the
> encryption.
>
> regards
>
> --
> Tomas Vondra http://www.2ndQuadrant.com
> PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
From | Date | Subject | |
---|---|---|---|
Next Message | dangal | 2019-10-07 20:52:41 | temporary files |
Previous Message | Bruce Momjian | 2019-10-07 20:12:52 | Re: Event Triggers and Dropping Objects |