61–70 of 98 posts
Earlier quoted context omitted.
That would explain all the vulnerabilities in systemd and Linux. They just aren't experienced enough. Linus needs to get in touch with an expert.
I’m looking forward to your efforts in rewriting it in Rust
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…
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…
> There's nothing preventing you from designing a nice well-encapsulated map/dictionary data structure in C When you write a set function for your map data structure, what type do you make the key parameter?
I would choose a key type that is natural to the environment and problem.. unsigned integers are useful. Which unsigned integer size? there are only a couple of practical answers to that.. unless there is some massive dataset, use a 32bit unsigned integer, like so much of the software does right now.
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…
Beyond a lack of memory safety, C has another issue that makes me dislike it for this kind of application: C has a very minimal set of built in data structures. Combined with a lack of generics, 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. This is almost invariably done with lots of pointers (since C has no better-const…
I do agree that generics are required for modern programming, but for some, the cost of complexity of modern languages (compared to C) and the importance of compatibility seem to outweigh the benefits.
"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?
It is however quite entertaining to read the predictable comments from Rust/Java/C++ fans who are upset that they didn't choose their favourite language.
> 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.
That said, this GitHub topic may have some pointers: https://github.com/topics/malware-samples
> 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.
(But still, note: A couple of months ago I wrote a low-level PDF parser—just parse the PDF file's bytes into PDF objects, nothing more—and fed it all the PDF files that happened to be present on my laptop, and ran into some files that (some) PDF viewers open, but even qpdf doesn't. I say "even" because qpdf is really good IMO.)
Earlier quoted context omitted.
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…
DARPA is funding fundamental research in this space, specifically through programs like SafeDocs[1]. [1]: https://www.darpa.mil/program/safe-documents
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…
> 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.