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
