| Age | Commit message (Collapse) | Author |
|---|
|
|
|
Everything builds in a batch build for me now, except for the OpenSSL
stuff, which fails due to me not having it available.
|
|
Remove direct inclusion of pkcs7 source from the mupdf project and
create a separate libpkcs7 project with others as dependants
|
|
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.
|
|
Keeping them up to date is difficult and prone to errors, so we move
setting the USE_OUTPUT_DEBUG_STRING and FZ_LARGEFILE flags to the source
instead of relying on project file definitions.
|
|
Only libcrypto is used to do checking of digital signatures.
The SSL library openssl is never used.
|
|
This will only be built in "DebugCommercial" "ReleaseCommercial" and
"MementoCommercial" configuration builds.
A note on the way MSVS solutions work; libluratech is listed as
a dependency of the executables - this applies to ALL configurations.
In order to stop normal builds failing when we have no source, we
set each non "Commercial" configuration to not build libluratech.
The linker still looks for the output from the libluratech stage
to link in though, so for all non "Commercial" configurations, we
have the libluratech stage set to produce output named " ". This
is copied into the linker command line, and all is happy.
The sole downside to this is that if we try to build libluratech
in "Debug" (say) rather than "DebugCommercial", the build will
fail at the library making step. This will never happen unless
we manually try to build that project in that configuration though.
|
|
Allows testing of SUPPORT_GPROOF builds on windows.
|
|
People worrying about the minimal extra memory this takes can
disable it if required.
|
|
A few casts are required within the code, along with a few #ifdef
changes.
Some tweaks to curl are required too.
|
|
We build MuPDF without NDEBUG defined in order to check assertions but
don't want Visual Studio's Output console flooded with warnings for
broken documents. So instead of always defining USE_OUTPUT_DEBUG_STRING
for debug builds under Windows, allow the VS solutions to define it
when desired and to omit it when not.
|
|
|
|
|
