Re: crypting prosrc in pg_proc

On Thu, Aug 09, 2007 at 04:42:19PM +0200, Hans-Juergen Schoenig wrote:

> the problem here is that vendors of appliances don't want people to
> spider their codes. this is a fact - it is not the idea of open
> source to do so but bloody reality. in addition to that people are
> not willing to code everything in C just to hide.

Well, then, they're out of luck.

> so, there has to be a concept to achieve this for stored procedures
> somehow.

Just because you want something does not mean that there must be a
way to achieve it.

> i am afraid the source level encryption is the easiest thing and most
> understandable thing to do.

It's easy and understandable, but it won't do anything for you,
because the code has to be decrypted automatically in order to run.
If it can be decrypted by the system, then it can obviously be
decrypted by someone who has superuser access to the system too. I
have seen systems that attempt this sort of "protection" anyway.
(Indeed, one might argue that all of the hopeless and failed copy
protection systems CDs and DVDs have come with are exactly this sort
of trick.) The fundamental fact is that, if you want users to be able
to use code that is interpreted, then you're never going to be able
to guarantee that the users can't also see that code.

Other equally useless, in my experience, techniques include code
obfuscation. You could probably bind things up in enough levels of
nested calls to various functions that mapping it out would be tricky
and tedious. Of course, this also means that maintaining the code is
a fairly significant pain.

I'll also note that I am not actually convinced these contortions do
anything to protect the system from people who want to figure out how
it works.

None of that, of course, does anything to relieve the pressure on you
to deliver the requested feature. But perhaps you can reason with
them. And they can always write it in C and deliver only compiled
object code; although whether anyone would be foolish enough to run
such object code without inspecting its safety is an excercise in
speculation I don't care to pursue.

A

--
Andrew Sullivan | ajs(at)crankycanuck(dot)ca
The plural of anecdote is not data.
--Roger Brinner