Re: crypting prosrc in pg_proc

Поиск
Список
Период
Сортировка
От Steve Atkins
Тема Re: crypting prosrc in pg_proc
Дата
Msg-id A67F5659-0E44-4E51-97B4-984AE7AFDD35@blighty.com
обсуждение исходный текст
Ответ на Re: crypting prosrc in pg_proc  (Gregory Stark <stark@enterprisedb.com>)
Ответы Re: crypting prosrc in pg_proc  (Decibel! <decibel@decibel.org>)
Список 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 по дате отправления:

Предыдущее
От: Sergiy Vyshnevetskiy
Дата:
Сообщение: Re: Fixing insecure security definer functions
Следующее
От: "Jonah H. Harris"
Дата:
Сообщение: Re: crypting prosrc in pg_proc