Now that we're just about there on the patch to invent trusted extensions [1], I'd like to start a discussion about whether to mark anything besides the trusted PLs as trusted. I think generally we ought to mark contrib modules as trusted if it's sane to do so; there's not much point in handing people plperl (even sandboxed) but not, say, hstore. I trawled through what's in contrib today and broke things down like this:
Certainly NO, as these allow external or low-level access: adminpack dblink file_fdw postgres_fdw pageinspect pg_buffercache pg_freespacemap pg_visibility pgstattuple Probably NO, if only because you'd need additional privileges to use these anyway: amcheck dict_xsyn hstore_plperlu hstore_plpython2u hstore_plpython3u hstore_plpythonu jsonb_plperlu jsonb_plpython2u jsonb_plpython3u jsonb_plpythonu ltree_plpython2u ltree_plpython3u ltree_plpythonu pg_prewarm pg_stat_statements Definitely candidates to mark trusted: citext cube dict_int (unlike dict_xsyn, this needs no external file) earthdistance (marginal usefulness though) fuzzystrmatch hstore hstore_plperl intagg (marginal usefulness though) intarray isn jsonb_plperl lo ltree pg_trgm pgcrypto seg tablefunc tcn tsm_system_rows tsm_system_time unaccent (needs external file, but the default one is useful) uuid-ossp Not sure what I think about these: bloom (are these useful in production?) btree_gin btree_gist pgrowlocks (seems safe, but are there security issues?) spi/autoinc (I doubt that these four are production grade) spi/insert_username spi/moddatetime spi/refint sslinfo (seems safe, but are there security issues?) xml2 (nominally safe, but deprecated, and libxml2 has been a fertile source of security issues) Any opinions about these, particularly the on-the-edge cases? Also, how should we document this, if we do it? Add a boilerplate sentence to each module's description about whether it is trusted or not? Put a table up at the front of Appendxix F? Both? I'm happy to go make this happen, once we have consensus on what should happen. regards, tom lane [1] https://www.postgresql.org/message-id/flat/5889.1566415762%40sss.pgh.pa.us