Should qpdf depend on gnutls?
I am the upstream author and the debian maintainer of qpdf.
At the request of RedHat, I have made an enhancement to qpdf that
allows an external library to be used for crypto functions rather than
using qpdf's native crypto implementations. The qpdf library includes
code to compute hashes with md5 and sha2 (256, 384, and 512) as well
as encryption functions for rc4 and aes256 with and without CBC.
Disabling insecure crypto is not a practical option because of the way
these things are used in the PDF spec, but it is possible create PDFs
that don't use insecure crypto by just using 256-bit encryption.
I can build qpdf 9.1 for Debian in one of three ways: 1) use only the
native crypto as in all previous releases, thus avoiding a dependency
on gnutls; 2) build only the gnutls crypto provider thus causing a
dependency on gnutls but eliminating the native crypto entirely; or 3)
building both crypto providers, in which case gnutls will be used by
default, but developers and end users will have the ability to select
the native crypto provider at runtime if desired.
Do you have an opinion about which way I should go? I believe RHEL and
Fedora are going to use the second option of building with only gnutls
and dropping native crypto, but I have also enjoyed the fact that qpdf
has so few build dependencies. It is possible that a future version of
qpdf may support digital signature, in which case I will definitely
have to add either openssl or gnutls as a dependency.
--Jay
Reply to: