| Age | Commit message (Collapse) | Author |
|---|
|
|
|
Add a version of pdf_check_signature function that reports no support,
for builds without openssl. This allows the removal of ifdefs from the
apps.
|
|
|
|
The mupdf build included an implimentation of the pkcs7 functions that
are needed for signing documents and verifying signatures, the
implementation being either an openssl-based one, or a stub that returned
errors. This commit removes the pkcs7 functions from the main mupdf
library.
For the sake of verification, there wasn't really a need for the pkcs7
functions to be part of mupdf. It was only the checking function that used
them. The checking function is now provided as a helper, outside of the
main build. The openssl-based pkcs7 functions area also supplied as a
helper. Users wishing to verify signatures can either use the checking
function directly, or use the source on which to base their own.
Document signing requires more integration between mupdf and pkcs7
because part of the process is performed at time of signing and part when
saving the document. Mupdf already had a pdf_pkcs7_signer object that
kept information between the two phases. That object has now been extended
to include the pkcs7 functions involved in signing, and the signing
function now requires such an object, rather than a file path to a
certificate. The openssl-based pkcs7 helper provides a function that, given
the path to a certificate, will return a pdf_pkcs7_signer object.
The intention is that different implementations can be produced for
different platforms, based on cryptographic routines built into the
operationg system. In each case, for the sake of document signing, the
routines would be wrapped up as a pdf_pkcs7_signer object.
|
|
It was only ever calling fz_lock for its own lock. This was
an abuse at best, and could potentially have caused trouble
with the deadlock detection code. Instead, lock the same lock,
but do so using custom (static) functions.
|
|
Don't mess with conditional compilation with LARGEFILE -- always expose
64-bit file offsets in our public API.
|
|
Update separations interface further to cope with whether spots
should be rendered separately, or as composite colors.
|
|
|
|
|
|
|
|
It seems likely that we'll want people to able to use the MuPDF
C API as well as the MuOfficeLib helper lib. We therefore need
a way to get fz_context and fz_document values out of MuOfficeLib.
Potential problems exist with people calling MuPDF C API functions
using an fz_context that is in use elsewhere. Similarly, if an
fz_document is in use in a background thread (for instance in a
page render), we need to ensure that it can't be used at the same
time elsewhere.
We therefore provide MuOffice{Lib,Doc,Page}_run functions that
allow this to happen safely. This largely insulates callers from the
complexities of having to clone contexts etc, it safely ensures
that exceptions cannot be propogated beyond the topmost fz_try/
fz_catch, and it ensures that appropriate locking is used.
|
|
Was returning errors on successful creation.
|
|
Avoid using statics to hold the mutexes. This is safer for
multiple-instantiation.
|
|
When destroying a thread, set the thread handle to NULL so
we know that subsequent calls shouldn't try to destroy it
again.
|
|
|
|
|
|
|
