On T, 2005-08-16 at 09:14 -0700, Joshua D. Drake wrote: > > Is there a sound reason to believe that pl/Ruby does not have the > > trusted/untrusted issue ? > > Sure... it hasn't been found.
"It hasn't been found" is a really weak reason for any security assumption, even for a programming language. It must be a feature designed in, or at least proved to some extent of research (like java). > We can play the it "might have" or "might > not have" game all day long but it won't get us anywhere. Today, and > yesterday pl/Ruby can be run trust/untrusted, pl/python can not. Otoh most of my trusted language needs are met by plpgsql. I use pl/python mostly where I *need* the untrusted features - linking to external modules, opening files, sendine email, ... > >>Ruby for good or bad is gaining a large following and has become a very > >>active language in a short period of time. It can also be trusted and > >>untrusted. > > > > > > Both of these things could be said about Python when it was about the > > same age Ruby is now. > > But they can't be said about Python now. :) How about : Python has gained a large following over a long period of time and has been a well established and widely used language for a long time meaning that most of its security related features can be assumed to be known ? > Again I love Python but I can't use it the way I want to in the database. > > >>I believe that unless plPython can either be fixed > > > > > > Fixed how ? > > Be able to be trusted. use jython inside of pl/java ;) > >>or is going to continue to move forward as a pl language > > > > Why is "movin forward" needed ? > > Why do we need air to breathe? It is all about usability. The plPython > feature set it quickly becoming obsolete by the other language that are > in and not in core. Heck plPHP as scary as that is can do more. What exact fetures you mean that you would miss in (hypothetical) untrusted python which can do in pl/Ruby or pl/PHP ? > >>that we should consider deprecating it and even removing it in 8.2 or 8.3. > > > > > > This argument reminds me of the "let's rewrite postgresql in C++" > > proposal that comes up every few months. > > Your kidding right? I am not suggesting anything remotely close to that > insane argument. All I am saying is that unless plPython can be made to > be trust I think it should be deprecated. Maybe we should just spell out the difference of pl and pl/U languages in even bigger letters ? It is not that untrusted languages will eat your data, just that you can do some db superuser level things with them if you are allowed to create them, even if you are not superuser yourself. > And no, doing a follow up with "Well, plC can't be trusted" isn't going > to work. C is a completely different beast then the other pl languages. How different? Actually I mostly use plpython as a way to avoid writing my pl functions in C. I get 98% of capabilities of plC with 10% of coding. And if you are really keen on getting trusted plC, you can use any of the free C interpreters as a starting point for that. > In replacement or addition to, I think that plRuby would be a good choice. No argument against that, but unless Ruby will have all the extra modules python has gathered along the years (and preferrably python syntax :) ), I strongly object against "deprecating it and even removing it in 8.2 or 8.3". -- Hannu Krosing <[EMAIL PROTECTED]> ---------------------------(end of broadcast)--------------------------- TIP 5: don't forget to increase your free space map settings