gnutls @3.4.15 should rely on p11-kit for trust store

[lbschenkel (Leonardo Brondani Schenkel)]

The upstream default for gnutls is that it relies on p11-kit as the default trust store. By using p11-kit as the trust store, gnutls automatically inherits the following features:

• automatically recognizes all the system-provided CA roots configured at build time
• recognizes any other trusted certificates that are be available in hardware tokens and marked as such
• allows the administrator to customize the trust for any certificate and/or blacklist them (for example, by adding them to ${prefix}/etc/openssl/blacklist)

At present the port overrides the default configuration and forces gnutls to use the curl CA bundle file exclusively, which turns off all the features above besides the first. I am attaching a patch that changes the configuration back to the upstream default so the other two features are re-enabled.

Note that the proposed change will have absolutely no impact to any existing users because:

• p11-kit in MacPorts is configured to use (and has a hard dependency on) curl-ca-bundle, and uses the bundle as the trust store, so installing gnutls will still result on curl-ca-bundle being installed and the exact same set of certificates will end up being in the trust store by default
• p11-kit is already a dependency of GnuTLS so there's no additional dependencies being introduced

As a power user that both uses hardware tokens and customizes the trust of the default set of root certificates (mainly by blacklisting some), I miss these two features dearly. I think re-enabling them is a no-brainer since not only it does not affect the experience of 'regular' users but it also brings the port closer to the default upstream behaviour.

[mf2k (Frank Schima)]

Thanks. FYI, you only need to attach the Portfile patch, not the complete Portfile.

[lbschenkel (Leonardo Brondani Schenkel)]

Yes, I know. I attached it by mistake. :-)

[Schamschula (Marius Schamschula)]

Thanks for pointing this out. This choice dates back to the previous maintainer.

r153609

[blair (Blair Zajac)]

This change broke wget against my own webserver:

$ wget https://www.orcaware.com/
--2016-10-06 17:40:30--  https://www.orcaware.com/
Resolving www.orcaware.com (www.orcaware.com)... 107.170.199.150
Connecting to www.orcaware.com (www.orcaware.com)|107.170.199.150|:443... connected.
ERROR: The certificate of ‘www.orcaware.com’ is not trusted.
ERROR: The certificate of ‘www.orcaware.com’ hasn't got a known issuer.

Backing down to the previous revision works.

[blair (Blair Zajac)]

Cc Me!

[Schamschula (Marius Schamschula)]

Replying to blair@…:

This change broke wget against my own webserver:

$ wget https://www.orcaware.com/
--2016-10-06 17:40:30--  https://www.orcaware.com/
Resolving www.orcaware.com (www.orcaware.com)... 107.170.199.150
Connecting to www.orcaware.com (www.orcaware.com)|107.170.199.150|:443... connected.
ERROR: The certificate of ‘www.orcaware.com’ is not trusted.
ERROR: The certificate of ‘www.orcaware.com’ hasn't got a known issuer.

Backing down to the previous revision works.

Hmm.

I do see the same issue with wget, but it works for me using curl @7.50.3_0 +ares+gnutls+http2.

Rebuilding wget made no difference.

[blair (Blair Zajac)]

I don't get why rebuilding wget would make a difference???

Can we revert r153609 until a solution is found?

BTW, my certs are from StartSSL, if that makes a difference.

[lbschenkel (Leonardo Brondani Schenkel)]

I can reproduce that. I'm investigating but I agree reverting in the meantime is a good idea to avoid disrupting users. Apologies for the wget breakage.

[Schamschula (Marius Schamschula)]

Reversed, with a revision bump: r153676

[lbschenkel (Leonardo Brondani Schenkel)]

I found the issue. It was my fault due to an oversight of my part.

The problem is that when explicitly calling --with-default-trust-store-pkcs11 without any arguments the configure script sets the value to yes, but later the gnutls code uses that value as a URI to initialize the trust store. "yes" being an invalid URI would cause no existing module to match and the trust store was initialized as empty.

The correct way is to pass --with-default-trust-store-pkcs11=pkcs11: to the configure script which means that all available p11-kit modules (marked with trust-policy: yes) will match. By default that will at least contain p11-kit-trust, which in MacPorts is configured to use the curl-ca-bundle.

I have tested this locally with gnutls-cli and wget and curl (with +gnutls) against the reported site and a number of other sites and everything works correctly now.

I'm updating the patch with the fix and I apologize once more for the inconvenience. Next time I'll be more careful and test more thoroughly.

[lbschenkel (Leonardo Brondani Schenkel)]

Is there any chance that this could get a new review? Thanks.

[Schamschula (Marius Schamschula)]

I tested the new patch locally, and found no problems: r153774