this is why i do like to try and parse shit myself for my own tools, not that thats without risk but i dont share my.code so its untargeted. however, to support a wide variety like this the tools are ok. most code honestly in a pdf will not target pdftotext , i think. i think it would target the thing people open pdfs with like browsers and maybe a few readers like adobe and foxit reader. pdftotext seems more like an 'academic target', like a nice exersize but not very fruitful in an actual attack. i might be wrong tho.

Citation indexes are the devil and Google is hell. Try as you might to avoid it but you're already on an index. Security through obscurity isn't secure or obscure in this modern age. https://www.tandfonline.com/doi/full/10.1080/03054985.2024.2...

That's a qualitatively different kind of security topic, though. On the one hand, we have a bug in a tool that reads a passive format with complete accuracy. On the other we have the need to sacrifice some amount of accuracy to avoid executing embedded code in a dynamic file format.

Couldn't or shouldn't each parser be run in a container with systemd-nspawn or LXC or another container runtime? (Even if all it's doing is reading a file format into process space as NX data not code as the current user)

NX bit: https://en.wikipedia.org/wiki/NX_bit

Executable-space protection > Limitations mentions JITs and ROP: https://en.wikipedia.org/wiki/Executable-space_protection

mprotect(), VirtualAlloc[Ex] and VirtualProtect[Ex],

"NX bit: does it protect the stack?" https://security.stackexchange.com/questions/47807/nx-bit-do...