Summary: | pdf_repair ignores encryption for documents using PDF 1.5's new xref format | ||
---|---|---|---|
Product: | MuPDF | Reporter: | zeniko |
Component: | mupdf | Assignee: | Tor Andersson <tor.andersson> |
Status: | RESOLVED FIXED | ||
Severity: | normal | CC: | sebastian.rasmussen |
Priority: | P4 | ||
Version: | unspecified | ||
Hardware: | PC | ||
OS: | Windows 7 | ||
URL: | http://code.google.com/p/sumatrapdf/issues/detail?id=1146 | ||
Customer: | Word Size: | --- |
Description
zeniko
2011-01-01 18:25:45 UTC
Looks like pdf_repair just ignores the Encrypt dict that would be needed to load the document. Actually pdf_repair catches the Encrypt dict and introduces it into the repaired trailer dictionary. But still arc4 is not used when decoding stream data. Aha, got it! The reason is the fact that we re-build the trailer dictionary. Since /Encrypt is usually an indirect reference it contains a pointer to the xref object . This is fine under normal circumstances, but at this occasion we create a _new_ xref object, hence all points ought to be updated... The previous comment might not have made sense. When repairing .pdfs the file is scanned through, locating all objects. While this takes place xref is nil so as not to dereference any indirect references. As of lately the /Encrypt dictionary object reference is grabbed while scanning, thus its xref pointer is nil. As a next step the reference is inserted into the newly re-build xref trailer. After the repair has completed the /Encrypt entry in the trailer is checked to see if the file is encrypted. This is done by calling fz_isdict() on the entry which in turn calls fz_resolveindirect() wherein the indirect object's xref pointer is checked. If the xref pointer is nil then fz_resolveindirect() returns nil whereby fz_isdict() claims it not to be a dictionary leading to the decision to consider the file as non-encrypted. The reason MuPDF has been able to avoid this in the past is because when pdfs were encountered, having issues such as the first xref object not being free (or objects numbers being one higher than the xref claims), the xref was simply resized without running pdf_repairxref() at all. By doing this the trailer was kept intact and its /Encrypt reference contained valid pointers to the xref. I have a proposed fix, and it's awaiting Tors approval. |