Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

Totally agree, this data should be supplied by a "page server" (analogous to a frame server in video production) over http using pdf.js so it can run in a browser based sandbox.

The risks of running this code are just way too high without an org level security policy about what access this compromised machine would have.



I keep going back and forth trying to figure out if this is sarcasm or not. Firstly it sounds sensible, then you're talking about PDF.js in a browser sandbox?!


Not sarcasm. When parsing untrusted, complex input with untrusted code, one should use multiple isolation domains.

    pgsql -> http -> [ firejail [ deno pdf.js (file:///untrusted.pdf) ] ]


Ok, so you're using deno with pdf.js instead of poppler. While Javascript is mostly 'memory safe' using all of deno, pdf.js and firejail make your attack surface huge and difficult to review or constrain and probably tank performance if used on a big dataset because you have to initialize the whole stack per request. All three of those tools have had significant CVE's too so adding more layers increases the amount of CVE's you have to deal with. I also don't see what firejail buys you when you constrain deno (or another parser) to a properly secured container or VM.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: