On Fri, Jun 3, 2022 at 5: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.
It's worth considering, here, that python supports the same ability to write files. And, so do shell scripts. And, so do C programs (which is where current J implementations get their ability to write files from). Etc. Basically, most of the content on github, as well as most apps, can be thought of as vulnerabilities, in that sense. And, as a consequence, we have to adopt a variety of measures to contain and isolate potential problems. Software development is potentially risky -- you can wipe your machine and possibly have to restore it from backups (for example). And, other problems can occur. That said, usually when people are talking about security problems in the context of computers it's based on exposure to adversarial network activities. And, to some degree, have approaches which help cope with those kinds of problems. (I can imagine uses for a J implementation with restricted file system access -- it would be rather inconvenient to use, and it wouldn't be for everyone. But some people would have fun with it. That said, the playground implementation approximately scratches that itch.) Thanks, -- Raul ---------------------------------------------------------------------- For information about J forums see http://www.jsoftware.com/forums.htm
