Re: crypting prosrc in pg_proc

From: "korry(dot)douglas" <korry(dot)douglas(at)enterprisedb(dot)com>
To: "Zdenek Kotala" <Zdenek(dot)Kotala(at)Sun(dot)COM>
Cc: "Hans-Juergen Schoenig" <postgres(at)cybertec(dot)at>, "Andrew Dunstan" <andrew(at)dunslane(dot)net>, "PostgreSQL-development" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: crypting prosrc in pg_proc
Date: 2007-08-09 15:17:33
Message-ID: 46BB300D.1020204@enterprisedb.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers


> My suggestion is to extend PL API and each PL language should offer
> wrap or encrypt function which generate encrypted code and this code
> will be store in the pg_proc. PL language will be responsible to
> detect if it raw or crypted code. PG_Dump will dump crypted procedure
> and author is responsible keep his uncrypted version in source
> repository.
That strategy assumes that there is no way to reproduce the source form
from the encrypted form. That means that the PL compiler must be able
to recognize two different languages (the unencrypted form and the
encrypted form). That may work for PL/pgSQL but it won't work for any
language where a third-party compiler is involved (unless the decryption
function produces an obfuscated source form that represents legitimate
code for the compiler in question).

The basic problem is this: if you have to decrypt the code in order to
give it to a compiler (PL/pgSQL, Java, Perl, ...) then there is a point
in time where the source code is in plaintext form - it would be trivial
to add an fprintf( stderr, "%s", plainTextForm ) to the PL handler to
steal the code.

-- Korry

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Decibel! 2007-08-09 15:17:49 Re: crypting prosrc in pg_proc
Previous Message Hans-Juergen Schoenig 2007-08-09 15:16:43 Re: crypting prosrc in pg_proc