yep. i mentioned npm, but there are a few more.

On Wed, Jan 10, 2018 at 12:56 PM, Erik Quanstrom <quanstro@quanstro.net>
wrote:

> it is also exploitable in node.js.
>
> On Jan 10, 2018 12:52, Skip Tavakkolian <skip.tavakkolian@gmail.com>
> wrote:
>
> i think "javascript in the browser" is implied here. and that is a HUGE
> gate to close.
>
> fortunately, we don't have such browsers in plan9 :)
>
> On Wed, Jan 10, 2018 at 11:41 AM, Erik Quanstrom <quanstro@quanstro.net>
> wrote:
>
> to be fair, this vulnerability can be exploited with plain old JavaScript.
>
> On Jan 10, 2018 11:32, Skip Tavakkolian <skip.tavakkolian@gmail.com>
> wrote:
>
> good advice. i agree with the wait-and-see. i'm not convinced that this
> issue is solvable.
>
> using pip, npm and all the other ways of importing random code from
> who-knows-where is insanity and plan9 systems (mostly?) avoid this practice.
> having dedicated auth and fs servers (don't allow cpu'ing) and using
> terminals for each user is a good practice.
> a terminal on an affected processor can still compromise your factotum
> data in memory. rpi3 is a safe choice and, for plan9, probably the best
> choice.
>
>
>
> On Wed, Jan 10, 2018 at 8:59 AM, <cinap_lenrek@felloff.net> wrote:
>
> wait and see if all these scrambled together mitigations actually work.
>
> 9front is not in the business of selling shared computing environments
> (or sell executable javascript ads) to untrusted strangers.
>
> that was never really safe to begin with. there will be bugs in software
> and hardware. and there will be side channels.
>
> if you are concerned about security and leaks then run your authentication
> server on a dedicated box and applications on your own terminal.
>
> --
> cinap
>
>
>
>
>
>