Thanks for the vote of confidence, but I was really thinking only of the J-Playground. I don't use the call dll capabilities, but I do think it would be wise to think about the ability of one to break out of the sandbox. I know nothing about the one the J-Playground is using, but it is worth considering.
On Fri, Jun 3, 2022, 2:31 AM Jan-Pieter Jacobs <[email protected]> wrote: > I think that Paul was referring to J in general, e.g. running on the > desktop. > > I have to say this could be an actual concern, and surely for e.g. > companies intending to adopt J for anything serious on computer inside a > trusted network, especially since it involves downloading binaries from the > J website that could be spoofed, or packages could be altered to download > from elsewhere. > > Ubuntu and a lot of big FOSS projects like Libre office (ok, other order of > magnitude, and more likely a target) sign their packages, so they can be > verified upon install. I think it wouldn't be a bad idea to do the same > with J installers (so the user can verify the download) and official > packages (ideally automatically verified upon installation). I think this > could be fairly easily accomplished with gpg. > > Perhaps J could also do a sanity check on its system tools (and perhaps > some official packages like jqt and jhs) by verifying their checksums at > startup. > > Just a thought > > Jan-Pieter > > On Fri, 3 Jun 2022, 00:23 Joe Bogner, <[email protected]> wrote: > > > I'm glad we're talking about this because there may be misconceptions of > > how things work or perhaps I am not seeing the issue. > > > > Your example, when run, will only affect the specific browser tab that > code > > is run in. If that browser tab is reloaded, it starts with a fresh > > temporary, in-memory file system. If a new browser tab is opened, it gets > > its own temporary in-memory file system. In other words, it does no harm > > except to that specific session. > > > > The J Playground does not touch the host operating system. It runs > > sandboxed in the browser. > > > > The risk to me is that someone could write some code that taxes the CPU > > (maybe mines cryptocurrency ;) ), but presumably a script like that will > be > > more easy to spot because the playground doesn't run code automatically. > > Or, someone may write some code that blows up the memory of the tab, > which > > causes the browser to kill the tab. Browsers have gotten quite good at > > keeping poor performing websites or operations from crushing the system. > > > > On Thu, Jun 2, 2022 at 5:56 PM Paul Jackson <[email protected]> wrote: > > > > > At the moment there is an open door to anyone who knows, or cares to > > learn > > > about J. > > > 'Testing' fwrite 'tmp/this.txt' > > > At a minimum, we could make the directories write protected from the > > > account running the interpreter. > > > > > > > > ---------------------------------------------------------------------- > > For information about J forums see http://www.jsoftware.com/forums.htm > > > ---------------------------------------------------------------------- > For information about J forums see http://www.jsoftware.com/forums.htm > ---------------------------------------------------------------------- For information about J forums see http://www.jsoftware.com/forums.htm
