bug#23759: 25.1.50; 25.1.50; open-tls-stream creates malformed gnutls-cli command if trusted cert files don't exist

[Ted Zlatanov]

On Sat, 2 Jul 2016 10:09:50 +0300 Konstantin Kliakhandler <kosta@slumpy.org> 
wrote: 

KK> The problem: `open-tls-stream' replaces %t with exactly one element, which
KK> is nil if none of gnutls-trustfiles is readable, and the first element of
KK> gnutls-trustfiles is more than one is readable.
KK> The Solution: In the patch I make the test iterate on all the trustfiles as
KK> a user might have more than one relevant. In addition, I made the default
KK> setting for tls-program have entries that do not explicitly specify the
KK> trustfile.

KK> One thing to note here perhaps, is that if (gnutls-trustfiles) returns an
KK> empty list and one has the %t substitution in one of the tls-program
KK> entries, then that entry will not be run at all. I feel that this is
KK> reasonable since by setting --x509cafile nil one makes gnutls-cli fail
KK> anyway.

As you said, one of the key points of your patch is this:

-  '("gnutls-cli --x509cafile %t -p %p %h"
+  '("gnutls-cli -p %p %h"
+    "gnutls-cli --x509cafile %t -p %p %h"

Which replaces the specific call with a generic call (no CA file
specified). This is probably less secure because it will use the system
CA trustfiles regardless of the user's preferred `gnutls-trustfiles', so
I'd rather not make it the first thing attempted.

KK> Finally, I'm experiencing the above behavior, as far as I can tell, by
KK> default in e.g. erc-tls. What is the proper way to move to the built in
KK> TLS? Is it likely to be something in my config or in the implementation of
KK> ERC?

On Mac OS X, you can use Homebrew to build it with all the nice
libraries, or use one of the pre-built binary packages.

brew update && brew reinstall emacs --HEAD --use-git-head --cocoa --with-gnutls 
--with-rsvg --with-imagemagick

On W32, you need the right DLLs installed.

Once the libraries are installed, you're all set, they'll be used
automatically.

Ted