External libraries for Windows are now built automatically in the
qpdf/external-libs repository and include openssl in addition to zlib
and jpeg. Use these, and update the Windows build to build with the
openssl crypto provider by default. We leave the native crypto
provider enabled in case there is a problem with openssl and also to
continue to exercise that code.
The jpeg library has some assembly code that is missed by the compiler
instrumentation used by memory sanitization. There is a runtime
environment variable that is used to work around this issue.
Specifically, if a stream had its stream data replaced and had
indirect /Filter or /DecodeParms, it would result in non-silent loss
of data and/or internal error.
There isn't really an issue with these files causing a real problem,
but malware and virus checkers trip on them, and the value to leaving
them in the test suite is too low to be worth the hassle.
Wildcard expansion is different in Windows from non-Windows and
sometimes requires special link options to work. Add tests that fail
if we link incorrectly.
OPENSSL_IS_BORINGSSL is not actually set by configure, so it will be
undefined until a BoringSSL header is included. Hence the #ifdef logic
in QPDFCrypto_openssl.h would usually never apply.
This still worked because evp.h transitively included BoringSSL's
cipher.h and digest.h, but the latter are the correct (documented)
headers.
By re-ordering the includes, we can ensure the macro is defined when we
use it.
Also: fix case in the header guards.
- Checks explicitly for versions >= 1.1.0 with pkg-config
- Refactor the fallback checks. Previously they were copied
from the gnutls logic, but could be slightly surprising (it's not
obvious that they're for the case where pkg-config returns a false
negative, and it's weird that the linker check overode the header check)
- Fix the AC_SEARCH_LIBS check to try -lcrypto instead of -lopenssl
(-lcrypto is the standard library OpenSSL ships the crypto symbols in).
- Fix the AC_SEARCH_LIBS check to look for EVP_MD_CTX_new, which is not
present in versions prior to 1.1.0.
Fixes qpdf/qpdf#429 (although I haven't verified on cygwin)
On large files with predominantly \n line endings, memchr(..'\r'..)
seems to waste a considerable amount of time searching for a line
ending candidate that we don't need.
On the Adobe PDF Reference Manual 1.7, this commit is 8x faster at
QPDF::processMemoryFile().
