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

71–80 of 98 posts

Re: New Ghostscript PDF interpreter

#71

Post by zinekeller »

mkl wrote: post #50

> 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.

Technically not all of these are malformed (sometimes the document is well-formed ISO PDF but the software won't accept it), but this corpora has a dump of all PDFs that were reported problematic in many software including Ghostscript, PDF.js (Mozilla) and PDFium (Chromium): https://www.pdfa.org/a-new-stressful-pdf-corpus/

(note that the majority of them are relatively-harmless rendering issues but some PDFs here have caused crashes or even RCEs and process takeovers for certain malicious PDFs)

Re: New Ghostscript PDF interpreter

#72

Post by wglb »

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.

The effort is massive and the experience to do so at scale is very rare.

Re: New Ghostscript PDF interpreter

#73

Post by tgflynn »

chrisseaton wrote: post #57
tgflynn wrote: post #55

Earlier quoted context omitted.

Type safety and encapsulation aren't the same thing. Encapsulation is about hiding implementation details from the user of an API, which is what the comment I originally replied to was claiming you couldn't do in C.

The void * is (should have been!) an implementation detail, and you're leaking it in the interface - that's not encapsulation. For example if I want to store a __int128 on a 64-bit machine I'll have to deal with stuff like memory allocation and lifetime myself, when the data structure should do that.

It's not an implementation detail, it is part of the interface. The data it points to belongs to the caller and the caller is responsible for managing it, just like anywhere else in C.

Re: New Ghostscript PDF interpreter

#74

Post by chrisseaton »

tgflynn wrote: post #73
chrisseaton wrote: post #57

Earlier quoted context omitted.

The void * is (should have been!) an implementation detail, and you're leaking it in the interface - that's not encapsulation. For example if I want to store a __int128 on a 64-bit machine I'll have to deal with stuff like memory allocation and lifetime myself, when the data structure should do that.

It's not an implementation detail, it is part of the interface. The data it points to belongs to the caller and the caller is responsible for managing it, just like anywhere else in C.

> The data it points to belongs to the caller and the caller is responsible for managing it

Going back to the start of the thread where you said you didn't understand this:

> this means that using, say, a dictionary means that quite a bit of the implementation gets hard coded into every site that uses the dictionary

You can see you've just said yourself what you were saying you didn't understand - with data structures in C you're responsible for manually managing things that the data structure would via things like generics in most other languages, with you having to instead hard-code them at the use-site to turn the data into something that can be pointed to and managing the lifetime.

Re: New Ghostscript PDF interpreter

#75

Post by hnick »

Because Acrobat will open these files, there is considerable pressure for Ghostscript to do so as well, though we do try to at least flag warnings to the user when something is found to be incorrect, giving the user a chance to intervene.

Anyone who has done PDF composition for a "print ready" job (what a lie) from a client has run into this so many times. All we have to do is rearrange the pages in the right sorted order, add some barcodes, and print, right? Acrobat can open the file, so why is your printer crashing? Ironically, some of those printers used an Adobe RIP in the toolchain and this conversion PDF->PS on the printer was where things went wrong (I once tracked down a crash where a font's gylph name definition in the dict was OK in PDF but invalid syntax in PS, due to a // resolving into an immediately evaluated name that doesn't exist) but it's not something a technician could help with.

It was so bad that Ghostscript was one of many tools - we'd throw a PDF through various toolchains to hope one of them saved it in a format that was well behaved. Anyway I'm almost sad I've moved on from that job now so I can't try it out with some real world files. But in the end most of the issues came down to fonts and people using workflows that involve generating single document PDFs and merging them, resulting in things like 1000 subset fonts which are nearly identical and consuming all the printer memory, so I'm not sure how well this would help.

Re: New Ghostscript PDF interpreter

#76

Post by srvmshr »

vfclists wrote: post #18

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

When people write code which doesn't have memory safety & lacks the compactness needed for a mature product, it is not C language's fault

C is a well tested compact language - the fact that Linux kernel, BSD kernels, device drivers and a whole lot of games and physics engines are written for performant systems is a testament to it's reliability.

Additionally, I think it's the sane move. A language which is hot cake today (Yes, Rust) may or may not be in fashion 5 years from now when there's a new hotcake. Choices are made keeping 10-15 years project development in mind

Re: New Ghostscript PDF interpreter

#77

Post by dhosek »

toddm wrote: post #14

Ghostscript (well, gv) got me through the 1990s and beyond as part of my TeX -> dvips -> gv workflow. Kudos and thank you to those who maintain it and the associated packages!

Yep, and I remember the moment of surprise and delight when I once included an eps file into my TeX output with some color and saw the color show up in my gv output.

Re: New Ghostscript PDF interpreter

#79

Post by POPOSYS »

lvh wrote: post #17
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…

We (Latacora) previously advised clients to encapsulate GhostScript processing in something with a hard security boundary (like a Lambda) and I am not expecting the new implementation to change that.

Is this AWS Lambda or what kind of "Lambda" is this about?

Re: New Ghostscript PDF interpreter

#80

Post by aforwardslash »

simias wrote: post #39
tgflynn wrote: post #13

Earlier quoted context omitted.

> this means that using, say, a dictionary means that quite a bit of the implementation gets hard coded into every site that uses the dictionary I don't understand this part of your comment. There's nothing preventing you from designing a nice well-encapsulated map/dictionary data structure in C and I'm sure there are many many libraries that do just that. I do agree though that having such basic data structures in t…

Lack of generics will do that, unless you consider that blindly casting `void ` all over the place counts as "well-encapsulated". Even with macro-soup designing a good agnostic dictionary implementation for C is rather challenging. Linked lists are okay* if you use something like the kernel's list.h, but even then it's macro-heavy and has its pitfalls. In my work as an embedded developer I still use C a lot and it's…

Except when you need to build from source; you'll need yet another whole compiler toolchain that may or may not behave well on a specific environment - eg, do you kow how well rust (or other "modern" language) works in late-nineties mips systems? The c compiler is the lowest common denominator.
Post reply on HN