Side comment for the list, on software engineering security practice...
If what you have to do with the PDF is simple to do to the raw PDF
format, and your code might be fed PDF files of provenance that you
don't control, it's probably better security not to involve Poppler.
https://nvd.nist.gov/vuln/search/results?adv_search=false&form_type=basic&results_type=overview&search_type=all&query=poppler
https://www.adobe.com/devnet/pdf.html
In the past, I've found that pure Racket is quite capable of parsing PDF
sufficient to do what I've needed to do for consulting clients (e.g.,
extracting editable forms data).
A compromise, if you don't want to implement anything in pure Racket,
but a command line tool can do what you need, is to call that command
line tool from Racket, keeping likely memory exploits&bugs from giving
you a hard-to-debug mess in your Racket VM memory space. If you want to
be extra careful, you can use various host OS features to isolate that
host process.
(Warnings: the PDF documentation is big, you'll appreciate why C and C++
programmers have difficulty implementing PDF without filling it with
vulnerabilities, and you'll also get to see some totalitarian-friendly
features that have been added to PDF.)
(Also, it's not just the apparent authors of the immediate PDF tool in
whom you have to have confidence -- some of the PDF tools include
ancient-ancient PS C code, as well as link a lot of other
known-problematic libraries, such as for 2D pixmaps and fonts.)
--
You received this message because you are subscribed to the Google Groups "Racket
Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to racket-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
