On Sat, Nov 09, 2019 at 07:10:44PM -0500, Jay Berkenbilt wrote:
> 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.
I'd recommend to go with 2); there's a lot of value in using a common /
scrutinised crypto library over a custom implementation and for all
practical purposes gnutls would not be an additional dep as systemd
already pulls it in on virtually every Linux system these days.
Cheers,
Moritz