3 ms·
Beside licensing issues I'm not sure the solution should be to link Poppler (which has a multiple CVE's every year on average) into the database server, especia
by bzzzt 2y ago
Beside licensing issues I'm not sure the solution should be to link Poppler (which has a multiple CVE's every year on average) into the database server, especially if you process untrusted data.
Seems to be a great way to gain access to the database server.
Functionally it looks useful, but if those kind of 'helpers' catch on there really should be a way to sandbox these 'parser' processes.
- sitkack 2y agoTotally 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.
- jenny91 2y agoI 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?!
- sitkack 2y agoNot sarcasm. When parsing untrusted, complex input with untrusted code, one should use multiple isolation domains. pgsql -> http -> [ firejail [ deno pdf.js (file:///untrusted.pdf) ] ]
- bzzzt 2y agoOk, 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.