Opened 2 years ago

Closed 2 years ago

#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) 2 years ago.
gnutls.patch (1.0 KB) - added by lbschenkel (Leonardo Brondani Schenkel) 2 years ago.

Download all attachments as: .zip

Change History (14)

Changed 2 years ago by lbschenkel (Leonardo Brondani Schenkel)

Attachment: Portfile added

comment:1 Changed 2 years 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 2 years ago by lbschenkel (Leonardo Brondani Schenkel)

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

comment:3 Changed 2 years ago by Schamschula (Marius Schamschula)

Resolution: fixed
Status: newclosed

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

r153609

comment:4 Changed 2 years ago by blair (Blair Zajac)

Resolution: fixed
Status: closedreopened

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 2 years ago by blair (Blair Zajac)

Cc: blair@… added

Cc Me!

comment:6 in reply to:  4 Changed 2 years 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 2 years 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 2 years 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 2 years ago by Schamschula (Marius Schamschula)

Reversed, with a revision bump: r153676

comment:10 Changed 2 years 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 2 years ago by lbschenkel (Leonardo Brondani Schenkel)

Attachment: gnutls.patch added

comment:11 Changed 2 years ago by lbschenkel (Leonardo Brondani Schenkel)

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

comment:12 Changed 2 years ago by Schamschula (Marius Schamschula)

Resolution: fixed
Status: reopenedclosed

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

Note: See TracTickets for help on using tickets.