Re: pulling libpqtypes from queue - Mailing list pgsql-hackers

Merlin Moncure wrote:
> On Tue, Apr 15, 2008 at 10:48 AM,  <tomas@tuxteam.de> wrote:
>>  On Tue, Apr 15, 2008 at 09:48:37AM -0400, Merlin Moncure wrote:
>>  > On Tue, Apr 15, 2008 at 9:36 AM, Alvaro Herrera
>>  > <alvherre@commandprompt.com> wrote:
>>
>>  > >  I expect you intend to get at least the hooks in, right?
>>  >
>>  > not likely.  Keep in mind, this is not how we really wanted to do
>>  > things in the first place.  We don't think this is the right strategy
>>  > for integrating libpqtypes with libpq.  It over-complicates things and
>>  > we don't really see a use case outside of libpqtypes.  If a reasonable
>>  > case can be made for putting the hooks in, we will consider it.  Can
>>  > you think of any good reasons for hooking libpq outside of our
>>  > intentions?
>>
>>  Yes, this one comes to mind:
>>
>>   From: sanjay sharma
>>   Subject: Submission of Feature Request : RFC- for Implementing
>>            Transparent Data Encryption in Postgres
>>   <http://archives.postgresql.org/pgsql-hackers/2008-03/msg01231.php>
>>
>>  I know that the original poster wanted to encrypt and decrypt things
>>  server-side, but as was noted in the thread this doesn't make that much
>>  sense because the decryption keys must be somehow kept around there.
>>
>>  But for doing it transparently client-side such libpq hooks might come
>>  in handy...
> 
> libpqtypes was designed to handle this with our without hooking. (the
> 'hooking' debate was mainly about exactly how libpq and libpqtypes was
> going to be separated).
> 
> libpqtypes had a superclassing concept (not much discussed on the
> lists) where you could introduce new type handlers that wrapped
> existing ones and was desgined exactly for things like this.  keep an
> eye on our upcoming pgfoundry project.
> 
> merlin
> 
> 

libpqtypes should be up on pgfoundry shortly.

/* register a new type named secure_text.  Make it a * sub-class of bytea.  Subclass means you can extend * the
behaviorof another type. */
 
PQregisterTypeHandler(conn, "secure_text=bytea",  put_secure_text, get_secure_text);

int put_secure_text(PGtypeArgs *args)
{  char secure_buf[1024];  char *text = va_arg(args->ap, char *);  size_t len = encrypt(secure_buf, text,
strlen(text));
  // tell bytea super class to put resulting bytea value  return args->super(args, len, secure_buf);
}

int get_secure_text(PGtypeArgs *args)
{  size_t len;  char *secure_text;  size_t user_buflen = va_arg(args->ap, size_t);  char *user_buf = va_arg(args->ap,
char*);
 
  // ask the super class, bytea, to get the bytea value  if(args->super(args, &len, &secure_text) == -1)    return -1;
  decrypt(user_buf, user_buflen, secure_text, len);  return 0;
}

/* put a secure_text into a pgparam, which will encrypt it * and send it to the server as a bytea.  The "*" is a *
pointerflag telling pqtypes to not make an internal copy * of the string (keep a direct pointer). */
 
PQputf(param, "%secure_text*", "encrypt me");

/* put it in the db, the last argument is resultFormat */
PQparamExec(conn, param, "INSERT INTO t VALUES ($1)", 1);

/* get a secure_text from a result, which will decrypt * the bytea field and return text to user. */
char text[1024];
PQgetf(res, tup_num, "%secure_text", field_num,  sizeof(text), text);

You could make the variable arguments for %secure_text include an 
encryption key if you want.

-- 
Andrew Chernow
eSilo, LLC
every bit counts
http://www.esilo.com/