Hacker News new | past | comments | ask | show | jobs | submit login

The authors and maintainers of that code. Any error or warning flagged by this change is something that really ought to be changed anyway because any unchecked array or pointer dereference is a potential security risk.



That's patently false, or we wouldn't resort to all kinds of tricks to convince the (moderately smart) Go compiler to elide bounds checks (that we know to be unnecessary) from inner loops where they degrade performance significantly.


> any unchecked array or pointer dereference is a potential security risk.

I take exception to this. Of course if I write once-test never, copying from google results and trying to hit jira metrics, then any safety feature in the language will filter out some of the toxic waste code I am producing.

If secure code is designed and engineered, like any other secure technical system would, the language used does not matter so much, but, unsurprisingly, needs to be easy to reason about formally.


Have you read the source code of Xpdf (the thing being exploited in the famous NSO Apple iMessage 0-click blah blah)?

I did (because I wrote an exploit for the bug after the Google blogpost, for curiosity), the code looks disgusting. The author (one poor guy) does not have the code in an online VCS and instead dump a source tarball every few months (or years). The upstream vulnerable code was fixed months after news outbreak.

My conclusion is if Apple had a choice it won't end up in iOS at all. Clearly, Apple already paid a lot of maintaining cost in this case (fixing bugs before upstream did), but what you asked for is a whole new level.


I think you conflating bugs. Apple doesn't use Xpdf as the basis of the PDF Framework. The NSO bug exploited a bug in the JBIG2 file format. The same implementation of this code was included in both Xpdf and the Apple PDF code. That is why Xpdf needed to also fix the same code.


Of course I mean the fact they use the JBIG2 part of Xpdf. You don't have to use Xpdf for processing PDF in order to use these `class JBIG2*` and you don't even need to patch it.


There is a well-maintained in-VCS less-disgusting version of Xpdf. It's called Poppler, and Apple chooses to not use it.


Popper is GPL licensed, so Apple cannot use it.

(If you're going to say "but they could use it if they relicensed all of iOS as GPL": don't be daft.)


I guess that is Apple's problem




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: