OpenSystemsDevelopment / qpdf

Also accept -accessibility=n with 256 bit keys even though it will be
ignored.

For std::string and std::vector, replace operator[] with at.  This was
done using an automated process.  See README.hardening for details.

Ideally, the library should never call assert outside of test code,
but it does in several places.  For some cases where the assertion
might conceivably fail because of a problem with the input data,
replace assertions with exceptions so that they can be trapped by the
calling application.  This commit surely misses some cases and
replaced some cases unnecessarily, but it should still be an
improvement.

4.2.0 was binary incompatible in spite of there being no deletions or
changes to any public methods.  As such, we have to bump the ABI and
are fixing some API breakage while we're at it.

Previous 4.3.0 target is now 5.1.0.

Thanks to Jiri Popelka from Red Hat for sending the output of a
Coverity run over qpdf.

Rework QPDFWriter to always track old object IDs and QPDFObjGen
instead of int, thus not discarding the generation number.  Switch to
QPDF::getCompressibleObjGen() to properly handle the case of an old
object eligible for compression that has a generation of other than
zero.

fopen was previuosly called wrapped by QUtil::fopen_wrapper, but
QUtil::safe_fopen does this itself, which is less cumbersome.

Put a specific comment marker next to every piece of code that MSVC
gives warning 4996 for.  This warning is generated for calls to
functions that Microsoft considers insecure or deprecated.  This
change is in preparation for fixing all these cases even though none
of them are actually incorrect or insecure as used in qpdf.  The
comment marker makes them easier to find so they can be fixed in
subsequent commits.

When preparing the trailer for writing to the new file, trim a copy of
the trailer instead of the original file's trailer.

When writing a new stream, always remove /Crypt even if we are not
otherwise able to filter the stream.

Original code was written before we could shallow copy objects, so all
the filtering was done by suppressing the output of certain keys and
replacing them with other keys.  Now we can simplify the code greatly
by modifying shallow copies of dictionaries in place.

Read and write support is implemented for /V=5 with /R=5 as well as
/R=6.  /R=5 is the deprecated encryption method used by Acrobat IX.
/R=6 is the encryption method used by PDF 2.0 from ISO 32000-2.

Test cases added in a future commit since they depend on /R=6 support.

All version operations are now fully aware of extension levels.

Allowing users to subclass InputSource and Pipeline to read and write
from/to arbitrary sources provides the maximum flexibility for users
who want to read and write from other than files or memory.

This fixes were to code added yesterday; the problems would not have
impacted any previously released code.  These are all changes related
to the possibility that copyEncryptionParameters may be called on
behalf a different QPDF than the one being written.

Method to copy encryption parameters from another file.  Adapted from
existing code to copy encryption parameters from the original file.

Throw an exception that directs the user to QPDF::copyForeignObject.

With QPDF allowing integers to contain 64-bit quantities, this change
is necessary to be able to linearize files whose sizes might be larger
than 10 digits.

This makes it possible to store offsets that are larger than 2 GB in
the trailer dictionary.

This just makes it safer to pull up this file in an editor.

off_t is used internally only when needed to talk to standard
libraries.  This requires that the "long long" type be supported by
the compiler.

Thanks Tobias Hoffmann for noticing the error.

Significantly improve the code's use of off_t for file offsets, size_t
for memory sizes, and integer types in cases where there has to be
compatibility with external interfaces.  Rework sections of the code
that would have prevented qpdf from working on files larger than 2 (or
maybe 4) GB in size.

…would probably never manifest itself without other code changes