#52508 closed defect (fixed)

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

Reported by: lbschenkel (Leonardo Brondani Schenkel) Owned by: Schamschula (Marius Schamschula)
Priority: Normal Milestone:
Component: ports Version: 2.3.4
Keywords: haspatch Cc: blair (Blair Zajac)
Port: gnutls

Description

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.

Attachments (2)

Portfile (4.0 KB) - added by lbschenkel (Leonardo Brondani Schenkel) 14 months ago.
gnutls.patch (1.0 KB) - added by lbschenkel (Leonardo Brondani Schenkel) 14 months ago.

Download all attachments as: .zip

Change History (14)

Changed 14 months ago by lbschenkel (Leonardo Brondani Schenkel)

comment:1 Changed 14 months ago by mf2k (Frank Schima)

  • Cc mps@… removed
  • Keywords haspatch added
  • Owner changed from macports-tickets@… to mps@…

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

comment:2 Changed 14 months ago by lbschenkel (Leonardo Brondani Schenkel)

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

comment:3 Changed 14 months ago by Schamschula (Marius Schamschula)

  • Resolution set to fixed
  • Status changed from new to closed

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

r153609

comment:4 follow-up: Changed 14 months ago by blair (Blair Zajac)

  • Resolution fixed deleted
  • Status changed from closed to reopened

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.

comment:5 Changed 14 months ago by blair (Blair Zajac)

  • Cc blair@… added

Cc Me!

comment:6 in reply to: ↑ 4 Changed 14 months ago by 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.

comment:7 Changed 14 months ago by 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.

comment:8 Changed 14 months ago by 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.

comment:9 Changed 14 months ago by Schamschula (Marius Schamschula)

Reversed, with a revision bump: r153676

comment:10 Changed 14 months ago by 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.

Changed 14 months ago by lbschenkel (Leonardo Brondani Schenkel)

comment:11 Changed 14 months ago by lbschenkel (Leonardo Brondani Schenkel)

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

comment:12 Changed 14 months ago by Schamschula (Marius Schamschula)

  • Resolution set to fixed
  • Status changed from reopened to closed

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

Note: See TracTickets for help on using tickets.