| Age | Commit message (Collapse) | Author |
|---|
|
|
|
|
|
|
|
An earlier commit changed the mode used to open a file for saving so that
it could also be read from. The mode used was rb+ independently of whether
the saving mode was incremental or not. Doing so neglected that for
non-incemental saves the file may not already exist in which case opening
rb+ will fail. This commit arranges that wb+ is used in the non-incremental
case.
|
|
|
|
Don't output linewidth as mitrerlimit. This confuses Acrobat.
|
|
Thanks to oss-fuzz for reporting this.
|
|
Thanks to oss-fuzz for reporting this.
|
|
Thanks to malc for spotting 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.
|
|
This provides a way for some output streams to also be read, a feature
needed for the sake of document signing. Currently this is supported only
for file output.
|
|
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.
|
|
|
|
Do not throw an exception, just ignore the faulty color profile.
|
|
Without deleteing it the local reference table may overflow.
|
|
|
|
The lock checking functions are always enabled in debug mode, but
since they are not thread safe they may not be used in a
multi-threaded application. Multi-threaded applications are
required to set their own locking functions so the lock checking
functions should only be run if the default locking functions
are in use.
|
|
|
|
|
|
Once a stream has thrown an exception or reached EOF,
don't allow further reading.
The EOF flag is reset when fz_seek is invoked.
|
|
|
|
The subarea rect used for lookups could mismatch the subarea returned
by the get_pixmap function due to adjusting to whole bytes. Refactor
and use a common subarea adjustment function.
Many image formats which do not support subarea tiles will decode
and cache the full image, so if a subarea tile cannot be found,
look for the full image tile as well.
|
|
|
|
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 the copy had as many reference counts as the original
pixmap which lead to leaks of pixmaps.
|
|
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.
|
|
|
|
|
|
|
|
This needs adding a fz_xml_doc type to hold the pool.
|
