Re: Should qpdf depend on gnutls?

["Jay Berkenbilt" <ejb@ql.org>]

I'm about to release qpdf 10. Someone contributed an openssl crypto provider. Do you think I should build with the qpdf packages for debian with 1) only gnutls, 2) only openssl, or 3) both gnutls and openssl? Option 3 allows users to select at runtime but makes qpdf dependent on both packages. I notice that systemd also depends on openssl. My impulse is to go with option 1 (gnutls only) because I really don't see any advantage in the OS package letting users choose at runtime which crypto to use, but including both cryptos probably doesn't ultimately affect what gets installed on anyone's system since openssl is basically always going to be there.

Opinions welcome. Thanks!

On Sun, Nov 10, 2019, at 9:10 PM, Jay Berkenbilt wrote:

Okay, thanks for all the response, public and private. There seems to be broad consensus to use the gnutls crypto and disable the native one, so that's what I'll do. Appreciate the advice!

--Jay

On Sun, Nov 10, 2019 at 2:05 PM Moritz Mühlenhoff <jmm@inutil.org> wrote:

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