From: | Allan Kamau <kamauallan(at)gmail(dot)com> |
---|---|
To: | pgsql-general <pgsql-general(at)postgresql(dot)org> |
Subject: | Re: Hide the code from users postgres |
Date: | 2010-06-24 21:59:37 |
Message-ID: | AANLkTimPtmdjVcBOHhtAQNznRFDztVT-JKDzHvHLnUOk@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
On Fri, Jun 25, 2010 at 12:28 AM, Dave Page <dpage(at)pgadmin(dot)org> wrote:
> On Thu, Jun 24, 2010 at 10:20 PM, Joshua D. Drake <jd(at)commandprompt(dot)com> wrote:
>> On Thu, 2010-06-24 at 22:18 +0100, Dave Page wrote:
>>
>>> > I have no problem with him trying to protect his hard earned work. I
>>> > just think he is trying to solve the wrong problem.
>>>
>>> It's a real problem faced by many businesses and solved by most
>>> commercial DBMSs. Of course, it's basically impossible to solve in the
>>> Open Source world, as there's nowhere to hide a key or obfuscation
>>> algorithm. If akp geek is able to use EnterpriseDB builds of Postgres,
>>> then he may want to look at PL/Secure, which will obfuscate his
>>> pl/pgsql code:
>>>
>>> http://www.enterprisedb.com/products/pl_secure_standard_server.do
>>
>> That's interesting... does it just turn it into bytecode?
>
> No, it runs it through a few different obfuscation algorithms to make
> it very difficult to decode without knowledge of them.
>
> --
> Dave Page
> EnterpriseDB UK: http://www.enterprisedb.com
> The Enterprise Postgres Company
>
Perhaps (I could be wrong here), there may be a way (even though I
don't really support the obfuscation, vendor lockup etc... idea).
1)Use a commercial DB (as mentioned previously), they seem to have
provided for this.
2)Use PostgreSQL and write all code into C functions and complied to a
given PostgreSQL installation.
Allan.
From | Date | Subject | |
---|---|---|---|
Next Message | Dave Page | 2010-06-24 22:04:24 | Re: Hide the code from users postgres |
Previous Message | Steve Singer | 2010-06-24 21:28:21 | Slony-I 2.0.4 released |