David Fetter <da...@fetter.org> writes: > I don't know about a *good* idea, but here's the one I've got.
> 1. Make a whitelist. This is what needs to work in order for a > language to be a fully functional trusted PL. Well, I pretty much lose interest right here, because this is already assuming that every potentially trusted PL is isomorphic in its capabilities. If that were so, there'd not be very much point in supporting multiple PLs. A good example here is R. I have no idea whether PL/R is trusted or trustworthy, but in any case the main point of supporting that PL is to allow access to the R statistical library. How does that fit into a whitelist designed for some other language? It doesn't. > 3. (the un-fun part) Write tests which attempt to do things not in > the whitelist. We can start from the vulnerabilities so far > discovered. And here is the *other* fatal problem: a whitelist does not in fact give any leverage at all for testing whether there is access to functionality outside the whitelist. (It might be useful if you could enforce the whitelist at some sufficiently low level of the language implementation, but as a matter of testing, it does nothing for you.) What you're suggesting isn't so much un-fun as un-possible. Given a maze of twisty little subroutines all different, how will you find out if any of them contain calls of unwanted functionality? If you think you can do something with this, go for it, but don't expect me to spend any of my time on it. regards, tom lane -- Sent via pgsql-hackers mailing list (email@example.com) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers