Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

New Ghostscript PDF interpreter

ghostscript.com

Post reply on HN
Print view View original

41–50 of 98 posts

Re: New Ghostscript PDF interpreter

#41

Post by madmoose »

aidos wrote: post #6

Does anyone know much about the Artifex team? How big it is etc? They seem to be the kings of working with PDFs. I’ve not really looked at the Ghostscript code (and I’m surprised to hear their interpreter was still in postscript), but I’ve looked through the mupdf code and what I saw was really nice. In any case, I appreciate the work they’ve done in providing fantastic tools to the world for decades now.

Strangely this appears to be a new implementation not based on MuPDF, so Artifex now has two implementations of a PDF interpreter.

I wonder what made them decide to reimplement it instead of reusing their existing code.

Re: New Ghostscript PDF interpreter

#43

Post by asdff »

neilv wrote: post #34

Years back, I raised how evolved Ghostscript had been over a very long time, together with the huge complexity of the PDF specs, as a potential source of vulnerabilities. (But maybe wasn't as much on people's radars, with all lower-hanging fruit of other technology choices and practices going on, outside of PDF.) New code for a large spec is also interesting for potential vulns, but maybe easier to get confidence abo…

Is there any work in this space on some oddball "contamination protocol" type of security? Like you would assume everything is contaminated and you do things that eliminate the potential for cross contamination entirely, like they do in lab settings with aseptic technique. In this case, it could mean printing out the contaminated pdf on a system you don't care about being contaminated, then scanning it with an airgapped scanner to recover a 'sterile' pdf. It seems convoluted but I'm sure for some applications that could be a good solution that requires no improvement to pdf protocol.

Re: New Ghostscript PDF interpreter

#44

Post by asdff »

vintagedave wrote: post #5

Given the mention of security issues in their custom PostScript extensions, and that PDF files are often malformed, I wonder why they chose C as the language for the new interpreter. I don't want to write a typical HN comment ( cough use Rust for everything :)) but surely there is _some_ better language for entirely new development of a secure and fast parser in 2022. The post has no explananation of this choice. Doe…

I don't even actively code with rust but just from the fact that its been packaged as a dependency has been enough of a headache for me. The latest issue is with some homebrew package that has rust as a dependency. It turns out on macos mojave rust needs to be built from source since there is no bottle. I let it build for a full day and it still didn't finish building, so I gave up. Then I installed rust independently with rustup and successfully linked that install to brew, which nearly worked, but failed with the cryptic "rustup could not choose a version of cargo to run..." error that I can't make any sense of, because the solution it gave for that error to download the latest stable release and set it as your toolchain with 'rustup default stable' didn't do anything because that was already done. The real salt on the wound is that modern google search bringing up nothing relevant.

Re: New Ghostscript PDF interpreter

#45

Post by kisamoto »

Not sure why this is being posted now as this is from March...

But anyway - I understand why they have changed their interpreter however the lack of major version bump threw me off. I use ps2pdf to optimize pdfs (long story short - makes their size smaller) and was alarmed when my pdfs suddenly ended up without the jpeg backgrounds. Instead, purely black (although this did result in a very small file size so who knows... :) )

Thankfully you can add `-d NEWPDF=false` to your command to use the old parser. I'm yet to submit a bug report but it would be nice if it was backwards compatible...

Re: New Ghostscript PDF interpreter

#46

Post by mepian »

"But Ghostscript’s PDF interpreter was, as noted, written in PostScript, and PostScript is not a great language for handling error conditions and recovering."

Isn't C, their chosen replacement of PostScript, also particularly bad at this?

Re: New Ghostscript PDF interpreter

#47

Post by daptaq »

mepian wrote: post #46

"But Ghostscript’s PDF interpreter was, as noted, written in PostScript, and PostScript is not a great language for handling error conditions and recovering." Isn't C, their chosen replacement of PostScript, also particularly bad at this?

I'd say a language is bad at error handling if it doesn't let you check if a procedure failed or not. What C does it that it compiles even if you ignore this, which is a different issue. Java, Rust, etc. wouldn't compile if you totally ignored it, but you that doesn't mean you have to do proper error handling, beyond satisfying the compiler/type system.

Re: New Ghostscript PDF interpreter

#48

Post by neilv »

asdff wrote: post #43
neilv wrote: post #34

Years back, I raised how evolved Ghostscript had been over a very long time, together with the huge complexity of the PDF specs, as a potential source of vulnerabilities. (But maybe wasn't as much on people's radars, with all lower-hanging fruit of other technology choices and practices going on, outside of PDF.) New code for a large spec is also interesting for potential vulns, but maybe easier to get confidence abo…

Is there any work in this space on some oddball "contamination protocol" type of security? Like you would assume everything is contaminated and you do things that eliminate the potential for cross contamination entirely, like they do in lab settings with aseptic technique. In this case, it could mean printing out the contaminated pdf on a system you don't care about being contaminated, then scanning it with an airgap…

I've heard of measures like that, including for the other direction (i.e., redacting documents without leaking information in the effectively opaque PDF format).

IMHO, having well-engineered tools handle data, and being conservative about the trust/privileges given externally-sourced data is at least complementary to the current "zero trust" thinking among networks and nodes.

(Example: Does your spreadsheet really arbitrary code execution, in an imperfect sandbox, for all your nontechnical users? Should what people might think is a self-contained standalone text document file really phone home, to disclose your activity and location, or have the potential to be remotely memory-holed/disabled, along with attendant added security risks from that added complexity and the additional requirements it puts on host systems/tools to try to enforce that questionable design?)

Re: New Ghostscript PDF interpreter

#49

Post by jcranmer »

vodou wrote: post #25
vfclists wrote: post #18

Using C sounds like it will bring a whole new list of exploits with it. Not good!!

C is not inherently unsafe. Sure, it hasn't "memory safety" as a feature. But there are loads of applications considered safe written in C. An experienced C programmer (with the help of tooling) can write safe C code. It is not impossible.

SQLite is the most stringently developed C code I'm aware of--the test suite maintains 100% branch coverage, routinely run through all of the sanitizers, and it is regularly fuzzed.

It still accumulates CVEs: https://www.sqlite.org/cves.html.

Re: New Ghostscript PDF interpreter

#50

Post by mkl »

> As time has gone on, and we have encountered more and more PDF files with ever more unexpected deviations from the specification

Does anyone know of a collection of malformed PDF files? It would be useful for testing PDF processing programs.

Post reply on HN