Re: pulling libpqtypes from queue

Merlin Moncure wrote:
> On Tue, Apr 15, 2008 at 10:48 AM, <tomas(at)tuxteam(dot)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(at)commandprompt(dot)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 behavior of 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
* pointer flag 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/