Skip site navigation (1) Skip section navigation (2)

Re: viewing source code

From: "Merlin Moncure" <mmoncure(at)gmail(dot)com>
To: "Alvaro Herrera" <alvherre(at)commandprompt(dot)com>
Cc: "Joshua D(dot) Drake" <jd(at)commandprompt(dot)com>, "Trevor Talbot" <quension(at)gmail(dot)com>, "Roberts, Jon" <Jon(dot)Roberts(at)asurion(dot)com>, "Kris Jurka" <books(at)ejurka(dot)com>, "Jonah H(dot) Harris" <jonah(dot)harris(at)gmail(dot)com>, "Bill Moran" <wmoran(at)collaborativefusion(dot)com>, pgsql-performance(at)postgresql(dot)org
Subject: Re: viewing source code
Date: 2007-12-20 20:35:42
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-performance
On Dec 20, 2007 3:07 PM, Alvaro Herrera <alvherre(at)commandprompt(dot)com> wrote:
> I don't think that makes any kind of sense.  Hiding prosrc should happen
> on a entirely different level from the language on which the function is
> written.  It's a completely orthogonal decision.  Besides, you probably
> don't want prosrc to be encrypted -- just not accesible to everyone, and
> it doesn't make sense to have a different _language_ to do that.

I kinda agree, kinda disagree on this point.  You may recall the huge
debate a while back where AndrewSN and others were promoting a revised
set of views to expose the system catalogs.  I thought this was a good
idea because the internal catalogs could be hidden from all but the su
and the views could be much easier to manipulate in that fashion.  The
proposal was however shot down for other reasons.

I don't really agree that wrapping pl/pgsql with encryptor/decryptor
is a bad idea.  It's fairly easy to do and very flexible (you don't
have to stop at encryption...for example you could run the code
through a pre-processor for token substitution).  We are not adding a
language in the semantic sense, wrapping an existing one.  Could
probably be extended to multiple languages if desired without too much
effort...I think it's only worthwhile bringing in core if you want to
hide the internals inside the syntax (CREATE ENCRYPTED FUNCTION

Key management is an issue but easily solved.  Uber simple solution is
to create a designated table holding the key(s) and use classic
permissions to guard it.  So I don't agree with your negative comments
in this direction but I'm not saying this is the only way to solve
this.  It is, however the only realistic way to do it without changes
to the project or breaking pgadmin.

> Also, having an encrypted source code means there must be a decryption
> key somewhere, which is a pain on itself.  And if you expose the crypted
> prosrc, you are exposing to brute force attacks (to which you are not if
> prosrc is hidden).

i don't buy the brute force argument at all...aes256 or blowfish are
perfectly safe.   The purpose of encryption is to move sensitive data
through public channels...otherwise, why encrypt?


In response to


pgsql-performance by date

Next:From: Andrew SullivanDate: 2007-12-20 20:52:14
Subject: Re: viewing source code
Previous:From: Joshua D. DrakeDate: 2007-12-20 20:17:34
Subject: Re: viewing source code

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group