Metaissue: Untrusted mode: plv8u #222
No definitive idea of when we'll get it, but anything using IO, or file-system reads requires an untrusted mode. We will dupe all tickets onto this issue, and place this in the queue as a milestone.
The text was updated successfully, but these errors were encountered:
some notes (going to go ahead and use this issue to write down some of the things that have been going through my head on this:
one thing that you'll see if you look at languages that are supported by RDS is that they're all trusted languages. in fact, none of the language extensions have the ability to be compiled untrusted. when you look at plpython and plperl, you'll see that they compile both extensions together by default. staying on RDS is very important, so in order to have an untrusted plv8, it should not compile both and make them both available.
this gives some options:
this will require a lot of writing and testing, as unlike plperl or plpython, these libraries are not built into the language itself, but have become de facto standards via nodejs.
I've already written a testing environment that would help out quite a bit: https://legitimatesounding.com/blog/unit_testing_in_postgresql_with_plv8.html
there would need to be a very large number of tests written to pull this off well.
I am happy to move
In process (this one is going to take me some time), but would be very useful for an untrusted extension.
lots to do overall, but nothing impossible, it's just going to take some time.
in the mean time, there are a couple of other initiatives in place that I'm trying to work on as well for plv8.
I think I've seen 5 or 6 different version of
A note on debugging:
I've created https://github.com/plv8/plv8u and have started breaking everything apart. looking at which modules need to be supported in which order.
I'm open to opinions.
Very cool to see there is work on plv8u although since we are currently living in RDS, it won't be of use to us.
Just wanted to check and make sure that the require stuff you are looking to support is going to be core, i.e. available in both trusted and un. I'm one of the many using a module loader with plv8 and it would be great to get first class support there.
Require will be core in untrusted, but I can likely port most of the core logic (sans file system support) into plv8. Unfortunately that still won't help until Debian is able to support modern v8, at which point you'd be able to use it in rds.
I do not plan to backport major functionality to unsupported versions (they receive critical bug updates, and security fixes but not new features).
Food for thought, the shim that handles fs features, perhaps we should only permit that access to
The two locations in question could be accessed via an npm install like this,
Please make sure to support a way for modules to be loaded from a table. Either some default in a
The core node.js API features I had to support in C++ were:
I didn't cover everything, but it was enough to get me what I needed.
Could we proxy the Chrome Developer Protocol though a foreign data wrapper (or a combination of custom wal messages/logical decoding, chunked notify/listen)? The PG community is often fond of using existing functionally to create new functionally. There are Lua and Go debuggers that are exposed though CDP so it's possible that a polyglot shim could bring debugging to trusted languages. It might be worth reaching out to the RDS team with a few proposals. A PG worker that exposes a CDP gateway to trusted languages using IAM/PG compatible authentication might tick the right boxes.