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 > [email protected] > https://lists.puredata.info/listinfo/pd-dev
signature.asc
Description: Digital signature
_______________________________________________ Pd-dev mailing list [email protected] https://lists.puredata.info/listinfo/pd-dev
