What a fun thread.
It does raise the old trust issue (I prefer that word to "security")
[shell] was always the obvious tool for mischief.
In the end Pd is a programming language - caveat emptor
Sandboxing has already been mentioned. It's not so easy to make cross platform, but a chrooted or cgroups constrained (semi-containerised) install should be possible for linux. Maybe that could be an install choice, for a "hardened Pd".
Careful code signing and review for Deken is probably a better future, and Pd community is small enough to manage that I think.
On Tue, Aug 31, 2021 at 04:51:00PM +0200, IOhannes m zmoelnig wrote:
On 8/31/21 4:37 PM, Antoine Rousseau wrote:
i wonder whether it would be possible (with Pd>=0.42) to create a patch that creates a gui-plugin on the fly. if this is true, then you can already do everything that [file] allows you to do - and much more
yes, but [file] will be extremely useful in the "-nogui" and libpd contexts.
yes definitely. and much more. i didn't write [file] to write exploits but to be useful.
BTW, and about the "exploits", I'm wondering if this would be feasible to implement a safety lock callable from a libpd based application, that would restrict the write permission (of every Pd object) to a given list of directories.
we could probably restrict `sys_open` and friends. however, externals are free to *not* use `sys_open` so that could be easily circumvented.
mfgasdr IOhannes
Pd-dev mailing list Pd-dev@lists.iem.at https://lists.puredata.info/listinfo/pd-dev