Re: crypting prosrc in pg_proc - Mailing list pgsql-hackers

From Steve Atkins
Subject Re: crypting prosrc in pg_proc
Date
Msg-id A67F5659-0E44-4E51-97B4-984AE7AFDD35@blighty.com
Whole thread Raw
In response to Re: crypting prosrc in pg_proc  (Gregory Stark <stark@enterprisedb.com>)
Responses Re: crypting prosrc in pg_proc  (Decibel! <decibel@decibel.org>)
List pgsql-hackers
On Aug 10, 2007, at 12:00 PM, Gregory Stark wrote:

> "Jonah H. Harris" <jonah.harris@gmail.com> writes:
>
>> Obfuscation doesn't really work, it just makes big wigs in companies
>> *think* it's not easily reversible.
>>
>> There is no real security.  With enough time and experience, anything
>> can be broken.
>
> But that said, I wonder if having something may be useful legally  
> for some
> users.
>
> If someone just went and did "select * from pg_proc" they could  
> claim they
> weren't violating their EULA or any protection you had put in  
> place. If they
> went through the trouble having to de-obfuscate it then you would  
> have a
> strong DMCA claim in the US.

If doing so would violate their contract with you then it'll violate
their contract (and make them liable for large amounts of liquidated
damages) whether they violate the DMCA or not.

If the code in question isn't important enough to your business that
you have a signed contract with those using it, then it's not really
that important.

>
> But Jonah's entirely right that there's no way to make it technically
> impossible to de-obfuscate. All you can do is make any casual  
> observer pause
> and decide to break your license agreement.

Code obfuscation is a bad non-solution to a problem that's far
better solved contractually (assuming it's a real problem, which
it often isn't).

Cheers,  Steve



pgsql-hackers by date:

Previous
From: Sergiy Vyshnevetskiy
Date:
Subject: Re: Fixing insecure security definer functions
Next
From: "Jonah H. Harris"
Date:
Subject: Re: crypting prosrc in pg_proc