On Dec 20, 2007 3:07 PM, Alvaro Herrera <alvherre@xxxxxxxxxxxxxxxxx> 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 foo...) 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? merlin ---------------------------(end of broadcast)--------------------------- TIP 5: don't forget to increase your free space map settings
