| Age | Commit message (Collapse) | Author |
|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
Without this change a resized cmap splay tree leads to using stale pointers.
|
|
|
|
Thanks to oss-fuzz for reporting this.
|
|
Don't output linewidth as mitrerlimit. This confuses Acrobat.
|
|
Thanks to oss-fuzz for reporting this.
|
|
Thanks to oss-fuzz for reporting this.
|
|
Because of the structure of openssl's signature checking, we temporarily
permit certain errors in the certificate trust stage, so that openssl will
continue onto the digest check. That way we can detect special error cases
such as the only failure being that a self-signed certificate is present.
This commit misses out one of the cases we'd missed.
|
|
|
|
Previously, signature verification worked only for file-based documents
and the file path had to be passed into the verification function.
|
|
This change achieves two goals. It allows signing to be performed even
when the document is obtained other than from a disk file. It also
reestablishes to a working state signing of file-based documents, a feature
that was broken due to complete_signatures being called after certain
tables, avaialble via the output options object, had been destroyed.
|
|
We'd neglected to specify binary mode when opening the file. Possibly
this affected only running under Windows.
|
|
Reinstate the separate consideration of errors relating to the
certificate trust checking phase.
Remove the key-usage records from the certificate before signature
verification. This is done so that openssl will recognise self
signed cerificates. openssl doesn't consider them as such when
the key usage doesn't include certificate signing.
|
|
The openssl-version check within Makerules has been updated to
ensure we include signature support only when 1.0.1u or later is
available. 1.0.1u is the version at which the API changes which
necessitated this commit were introduced.
|
|
|
|
We need both RC4 and AES encryption. RC4 is a straight reversable
stream, and our AES library knows how to encrypt as well as decrypt,
so it's "just" a matter of calling them correctly.
We therefore expose a generic "encrypt this data" routine (and a
matching "how long will the data be once encrypted" routine) within
pdf-crypt.c.
We then extend our our PDF object output routines to call these.
This is enough to get encrypted data preserved over calls to mutool
clean. Unfortunately the created files aren't readable, due to 2
further problems, also fixed here.
Firstly, mutool clean does not preserve the Encrypt entry in the
trailer. This is a simple fix.
Secondly, we are required NOT to encrypt the Encrypt entry. This
requires us to spot the crypt entry and to special case it.
|
|
A customer reports that even after text has been redacted, we can
still search for the redacted text. The example file supplied had
many instances of the word 'words', and 4 instances of 'apple'.
The 'apple' instances were redacted, and the document saved out.
2 such instances were on the first page; when we searched for
'apple' acrobat would find the word after the first removed
instance of apple, then find the word 2 after the second removed
instance of apple.
After much head scratching and cutting down of the file, it
appears that the information genuinely isn't in the file. Acrobat
is somehow remembering it. It appears to be doing this using the
'ID' entries in the trailer dict.
My suspicion is that Acrobat has cached the text extraction from
the original document, and is using this on all files that match
the IDs. Change the IDs (or remove them) and the problem goes away.
The spec says that the ID should be 2 bytestrings in an array. The
first is supposed to stay the same in all versions of a file (i.e.
it shows the *original* version of the file, and it is the one that
is used by encrypt).
The second bytestring is supposed to change more often, so here we
simply return a new random string on each writing.
|
|
Previously if a variable text annotation with a default appearance
string had multiple 'Tf' operators all but the last font name would
leak.
|
|
Previously the borrowed colorspace was dropped when updating annotation
appearances, leading to use after free warnings from valgrind/ASAN.
|
|
|
|
|
|
This is true because they are now limited below PDF_MAX_OBJECT_NUMBER.
|
|
|
|
|
|
|
|
|
|
This ensures that:
* xref tables with objects pointers do not grow out of bounds.
* other readers, e.g. Adobe Acrobat can parse PDFs written by mupdf.
|
|
Return error tokens when parsing numbers with trailing garbage rather than
ignoring the extra characters.
Also handle error tokens more gracefully in array and dictionary parsing.
Treat error tokens as the 'null' keyword and continue parsing.
|
|
This goes well with the 'mutool clean -d' decompression option to debug
content streams, without doing the sanitize optimization pass.
|
|
If the first TJ we meet in a file has an adjustment, but no chars,
then we end up calling 'adjustment' without ever having set
fontdesc. This causes a crash.
Fix it here.
|
|
|
|
Future proof the API for the Year 2038 problem.
|
|
|
|
|
|
Also clarify that a copy of author/contents is returned, and that
the caller must free them.
|
|
Create a PDF 'text string' type string from a UTF-8 input string.
If the input is plain ASCII, keep it as is, otherwise re-encode it
as UTF-16BE.
|
|
|
|
|
|
|
|
|
|
|
|
Remove code left over from development that is now wrong.
We should have default colorspaces in the system, even in
NON_ICC builds.
|
|
Also wrap their contents in q/Q, so they can't screw up the
rest of the stream.
|
|
Otherwise we can get empty bbox values.
|
|
Hold 2 instances of a structure, rather than a structure with
2 of each fields in it.
Also, correct the logic for when we send color changes.
|
