Re: pgcrypto question

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

In response to

Browse pgsql-general by date

  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