Subject: CVS commit: pkgsrc/print/qpdf
From: Ryo ONODERA
Date: 2019-12-04 14:05:20
Message id: 20191204130520.DB47AFA97@cvs.NetBSD.org

Log Message:
Update to 9.1.0

Changelog:
2019-11-17  Jay Berkenbilt  <ejb@ql.org>

	* 9.1.0: release

2019-11-09  Jay Berkenbilt  <ejb@ql.org>

	* 9.1.rc1: release

	* Improve behavior of wildcard expansion for msvc executable when
	run from the Windows cmd.exe shell. Unlike in UNIX environments,
	Windows leaves it up to the executable to expand its own
	wildcards. Fixes #224.

	* When reading /P from the encryption dictionary, use static_cast
	instead of QIntC to convert the value to a signed integer. The
	value of /P is a bit field, and PDF files have been found in the
	wild where /P is represented as an unsigned integer even though
	the spec states that it is a signed 32-bit value. By using
	static_cast, we allow qpdf to compensate for writers that
	incorrectly represent the correct bit field as an unsigned value.
	Fixes #382.

2019-11-05  Jay Berkenbilt  <ejb@ql.org>

	* Add support for pluggable crypto providers, enabling multiple
	implementations of the cryptographic functions needed by qpdf.
	This feature was added by request of Red Hat, which recognized the
	use of qpdf's native crypto implementations as a potential
	security liability, preferring instead to get all crypto
	functionality from a third-party library that receives a lot of
	scrutiny. However it was also important to me to not impose any
	unnecessary third party dependencies on my users or packagers,
	some of which build qpdf for lots of environments, some of which
	may not easily support gnutls. Starting in qpdf 9.1.0, it is be
	possible to build qpdf with both the native and gnutls crypto
	providers or with either in isolation. In support of this feature,
	new classes QPDFCryptoProvider and QPDFCryptoImpl have been added
	to the public interface. See QPDFCryptoImpl.hh for details about
	adding your own crypto provider and QPDFCryptoProvider.hh for
	details about choosing which one is used. Note that selection of
	crypto providers is invisible to anyone who doesn't explicitly
	care. Neither end users nor developers have to be concerned about
	it.

	* The environment variable QPDF_CRYPTO_PROVIDER can be used to
	override qpdf's default choice of crypto provider. The
	--show-crypto flag to the qpdf CLI can be used to present a list
	of supported crypto providers with the default provider always
	listed first.

	* Add gnutls crypto provider. Thanks to Zdenek Dohnal for
	contributing the code that I ultimately used in the gnutls crypto
	provider and for engaging in an extended discussion about this
	feature. Fixes #218.

2019-10-22  Jay Berkenbilt  <ejb@ql.org>

	* Incorporate changes from Masamichi Hosoda <trueroad@trueroad.jp>
	to properly handle signature in the following ways:
	  - Always represent /Contents in a signature dictionary as a hex
	    string
	  - Do not compress signature dictionaries when generating object
	    streams
	  - Do not encrypt/decrypt the /Contents field of the signature
	    dictionary when creating or reading encrypted files

	* Incorporate changes from Masamichi Hosoda <trueroad@trueroad.jp>
	to add additional methods for making it possible to gain deeper
	insight into cross reference tables and object renumbering. These
	new API calls make it possible for applications to go into PDF
	files created by qpdf and make changes to them that go beyond
	working with the PDF at the object level. The specific use case
	for these changes was to write an external tool to perform digital
	signature, but there could be other uses as well. New methods
	include the following, all of which are described in their
	respective headers:
	  - QPDF::getXRefTable()
	  - QPDFObjectHandle::getParsedOffset()
	  - QPDFWriter::getRenumberedObjGen(QPDFObjGen)
	  - QPDFWriter::getWrittenXRefTable()

Files:
RevisionActionfile
1.32modifypkgsrc/print/qpdf/Makefile
1.10modifypkgsrc/print/qpdf/PLIST
1.27modifypkgsrc/print/qpdf/distinfo