Builtin GnuTLS support and certificate verification

Builtin GnuTLS support and certificate verification

[Vincent Bernat]

Hi!

Now that Gnus is able to use the builtin TLS support shipped with Emacs,
we have no way to verify the remote certificate which leaves us open to
man-in-the-middle attacks.

Previously, changing `tls-program` to not use the `--insecure` switch
mades the deal.  Emacs builtin GNU TLS support allows certificate
verification but each application needs to enable it explicitely. I
didn't find any user switch to enable it globally or per application. Of
all the applications using GNU TLS, I have not found any that enables
this certificate verification stuff.

Is there a way to enable certificate verification for Gnus? If not, is
there a way to force the old way to do TLS (by using an external
program)?
-- 
Make sure all variables are initialised before use.
            - The Elements of Programming Style (Kernighan & Plauger)

Re: Builtin GnuTLS support and certificate verification

[Julien Danjou]

[-- Attachment #1: Type: text/plain, Size: 654 bytes --]

On Sat, Nov 02 2013, Vincent Bernat wrote:

> Is there a way to enable certificate verification for Gnus? If not, is
> there a way to force the old way to do TLS (by using an external
> program)?

This has been on my TODO list a year. There was a thread I launched on
emacs-devel about that a year ago with Ted:

  http://lists.gnu.org/archive/html/emacs-devel/2012-09/msg00154.html
  http://lists.gnu.org/archive/html/emacs-devel/2012-12/msg00575.html

I didn't have time to dig since then, but I'd appreciate any hint on
this subject. :)

-- 
Julien Danjou
# Free Software hacker # independent consultant
# http://julien.danjou.info

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 835 bytes --]

Re: Builtin GnuTLS support and certificate verification

[Vincent Bernat]

 ❦  2 novembre 2013 12:27 CET, Julien Danjou <julien@danjou.info> :

>> Is there a way to enable certificate verification for Gnus? If not, is
>> there a way to force the old way to do TLS (by using an external
>> program)?
>
> This has been on my TODO list a year. There was a thread I launched on
> emacs-devel about that a year ago with Ted:
>
>   http://lists.gnu.org/archive/html/emacs-devel/2012-09/msg00154.html
>   http://lists.gnu.org/archive/html/emacs-devel/2012-12/msg00575.html
>
> I didn't have time to dig since then, but I'd appreciate any hint on
> this subject. :)

OK, I have just tested myself with:

#v+
(gnutls-negotiate
 :process (open-network-stream "test" nil "www.dailymotion.com" 443)
 :hostname "www.dailymotion.com"
 :verify-hostname-error t
 :verify-error t)
#v-

I don't know what "verify-error" is for since verify-hostname-error
seems to handle any error like certificate expired, mismatched name or
unknown root certificate. Example when the certificate is expired:

#v+
(gnutls-negotiate
 :process (open-network-stream "test" nil "www.pcwebshop.co.uk" 443)
 :hostname "www.pcwebshop.co.uk"
 :verify-hostname-error t
 :verify-error t)
#v-

It works for me. Now, if I understand correctly, you are also trying to
use `:trustfiles`. 

#v+
(gnutls-negotiate
 :process (open-network-stream "test" nil "awesome.naquadah.org" 443)
 :hostname "awesome.naquadah.org"
 :verify-hostname-error t
 :verify-error t)
#v-

I get an error. Now, I extract the certificate and specify it with
trustfiles option:

#v+
(gnutls-negotiate
 :process (open-network-stream "test" nil "awesome.naquadah.org" 443)
 :hostname "awesome.naquadah.org"
 :trustfiles '("/home/bernat/tmp/root.crt")
 :verify-hostname-error t
 :verify-error t)
#v-

And it works.

I am using Emacs 24.3 from Debian unstable. So far, it seems that the
builtin support is working.
-- 
printk("??? No FDIV bug? Lucky you...\n");
	2.2.16 /usr/src/linux/include/asm-i386/bugs.h

Re: Builtin GnuTLS support and certificate verification

[Vincent Bernat]

 ❦  2 novembre 2013 18:40 CET, Vincent Bernat <bernat@luffy.cx> :

>>> Is there a way to enable certificate verification for Gnus? If not, is
>>> there a way to force the old way to do TLS (by using an external
>>> program)?
>>
>> This has been on my TODO list a year. There was a thread I launched on
>> emacs-devel about that a year ago with Ted:
>>
>>   http://lists.gnu.org/archive/html/emacs-devel/2012-09/msg00154.html
>>   http://lists.gnu.org/archive/html/emacs-devel/2012-12/msg00575.html
>>
>> I didn't have time to dig since then, but I'd appreciate any hint on
>> this subject. :)
>
> OK, I have just tested myself with:
[...]

I have been pointed to this bug report too:
 http://debbugs.gnu.org/cgi/bugreport.cgi?bug=13374
-- 
10.0 times 0.1 is hardly ever 1.0.
            - The Elements of Programming Style (Kernighan & Plauger)

Re: Builtin GnuTLS support and certificate verification

[Ted Zlatanov]

On Sat, 02 Nov 2013 18:40:31 +0100 Vincent Bernat <bernat@luffy.cx> wrote: 

VB>  ❦  2 novembre 2013 12:27 CET, Julien Danjou <julien@danjou.info> :
>>> Is there a way to enable certificate verification for Gnus? If not, is
>>> there a way to force the old way to do TLS (by using an external
>>> program)?
>> 
>> This has been on my TODO list a year. There was a thread I launched on
>> emacs-devel about that a year ago with Ted:
>> 
>> http://lists.gnu.org/archive/html/emacs-devel/2012-09/msg00154.html
>> http://lists.gnu.org/archive/html/emacs-devel/2012-12/msg00575.html
>> 
>> I didn't have time to dig since then, but I'd appreciate any hint on
>> this subject. :)

VB> OK, I have just tested myself with:
VB> #v+
VB> (gnutls-negotiate
VB>  :process (open-network-stream "test" nil "www.dailymotion.com" 443)
VB>  :hostname "www.dailymotion.com"
VB>  :verify-hostname-error t
VB>  :verify-error t)
VB> #v-

VB> I don't know what "verify-error" is for since verify-hostname-error
VB> seems to handle any error like certificate expired, mismatched name or
VB> unknown root certificate.

According to gnutls.el:gnutls-negotiate:

When VERIFY-HOSTNAME-ERROR is not nil, an error will be raised
when the hostname does not match the presented certificate's host
name.  The exact verification algorithm is a basic implementation
of the matching described in RFC2818 (HTTPS), which takes into
account wildcards, and the DNSName/IPAddress subject alternative
name PKIX extension.  See GnuTLS' gnutls_x509_crt_check_hostname
for details.  When VERIFY-HOSTNAME-ERROR is nil, only a warning
will be issued.

When VERIFY-ERROR is not nil, an error will be raised when the
peer certificate verification fails as per GnuTLS'
gnutls_certificate_verify_peers2.  Otherwise, only warnings will
be shown about the verification failure.

`verify-error', however, is missing from the docstring of
gnutls.c:gnutls-boot and there's just a commented-out line in the
function:

  /* Lisp_Object verify_error; */

and the verification code, as you observed, does all the peer
verification based on `verify-hostname-error'.  I think this is my
error; this code:

  if (peer_verification != 0)
    {
      if (NILP (verify_hostname_error))
	GNUTLS_LOG2 (1, max_log_level, "certificate validation failed:",
		     c_hostname);
      else
	{
	  emacs_gnutls_deinit (proc);
	  error ("Certificate validation failed %s, verification code %d",
		 c_hostname, peer_verification);
	}
    }

should have been using `verify_error' instead.

Could you double-check my investigation and confirm?  If you agree, I
will make the change and update the bug report.

VB> It works for me. Now, if I understand correctly, you are also trying to
VB> use `:trustfiles`. 
VB> #v+
VB> (gnutls-negotiate
VB>  :process (open-network-stream "test" nil "awesome.naquadah.org" 443)
VB>  :hostname "awesome.naquadah.org"
VB>  :verify-hostname-error t
VB>  :verify-error t)
VB> #v-

VB> I get an error. Now, I extract the certificate and specify it with
VB> trustfiles option:
VB> #v+
VB> (gnutls-negotiate
VB>  :process (open-network-stream "test" nil "awesome.naquadah.org" 443)
VB>  :hostname "awesome.naquadah.org"
VB>  :trustfiles '("/home/bernat/tmp/root.crt")
VB>  :verify-hostname-error t
VB>  :verify-error t)
VB> #v-

VB> And it works.

There is a default list of trustfiles in `gnutls-trustfiles'.  It will
be used in the first case you show.

Ted

Re: Builtin GnuTLS support and certificate verification

[Vincent Bernat]

 ❦  3 novembre 2013 12:53 CET, Ted Zlatanov <tzz@lifelogs.com> :

> `verify-error', however, is missing from the docstring of
> gnutls.c:gnutls-boot and there's just a commented-out line in the
> function:
>
>   /* Lisp_Object verify_error; */
>
> and the verification code, as you observed, does all the peer
> verification based on `verify-hostname-error'.  I think this is my
> error; this code:
>
>   if (peer_verification != 0)
>     {
>       if (NILP (verify_hostname_error))
> 	GNUTLS_LOG2 (1, max_log_level, "certificate validation failed:",
> 		     c_hostname);
>       else
> 	{
> 	  emacs_gnutls_deinit (proc);
> 	  error ("Certificate validation failed %s, verification code %d",
> 		 c_hostname, peer_verification);
> 	}
>     }
>
> should have been using `verify_error' instead.
>
> Could you double-check my investigation and confirm?  If you agree, I
> will make the change and update the bug report.

I agree with you but I find odd to have two verification algorithms. I
don't see the point of verifying the hostname if the certificate is
invalid on some other points and I don't see the point of not verifying
the hostname.

I mean, if you accept any valid certificate, it is trivial for me to
present you with the certificate of my website. If you accept any
invalid certificate with the right hostname, it is also trivial for me
to build a self-signed certificate with the right hostname.

Now, if `:trustfiles` is set to a non standard location, the first case
may makes sense: I don't check the hostname but the certificate should
only be valid if signed by some other certificate that I specify
exactly. However, in which case could this be useful? Either you have
signed yourself the certificate and it is trivial to set the appropriate
name or you bought it and I could buy a certificate from the same shop
with another name.

So, for me, there should be only one verification algorithm. We are not
in the ideal case for this because we only have one algorithm but its
name does not exactly describe it.

Maybe you could just alias verify-error and verify-hostname-error and
say in the documentation that they do the same and that
verify-hostname-error will be removed at some point?
-- 
printk("Illegal format on cdrom.  Pester manufacturer.\n"); 
	2.2.16 /usr/src/linux/fs/isofs/inode.c

Re: Builtin GnuTLS support and certificate verification

[Ted Zlatanov]

On Mon, 04 Nov 2013 20:54:26 +0100 Vincent Bernat <bernat@luffy.cx> wrote: 

VB> I agree with you but I find odd to have two verification algorithms. I
VB> don't see the point of verifying the hostname if the certificate is
VB> invalid on some other points and I don't see the point of not verifying
VB> the hostname.

IIRC, the hostname is an optional part of a certificate and certificates
are not the only form of authentication.  So there are two cases (verify
connection and verify certificate hostname).

VB> I mean, if you accept any valid certificate, it is trivial for me to
VB> present you with the certificate of my website. If you accept any
VB> invalid certificate with the right hostname, it is also trivial for me
VB> to build a self-signed certificate with the right hostname.

I think verifying the hostname is a subset of verifying the remote in
general.  I just didn't express it well.

VB> So, for me, there should be only one verification algorithm. We are not
VB> in the ideal case for this because we only have one algorithm but its
VB> name does not exactly describe it.

VB> Maybe you could just alias verify-error and verify-hostname-error and
VB> say in the documentation that they do the same and that
VB> verify-hostname-error will be removed at some point?

I think :verify-error should be a list; when it contains 'x509-hostname
then we behave like :verify-hostname-error does now, for backwards
compatibility.  But otherwise we'll add extra checks to the list, not as
top-level options to `gnutls-boot'.  It's easy to put a Customize
interface on top of that.

Ted

Re: Builtin GnuTLS support and certificate verification

[Vincent Bernat]

 ❦  4 novembre 2013 22:10 CET, Ted Zlatanov <tzz@lifelogs.com> :

> VB> So, for me, there should be only one verification algorithm. We are not
> VB> in the ideal case for this because we only have one algorithm but its
> VB> name does not exactly describe it.
>
> VB> Maybe you could just alias verify-error and verify-hostname-error and
> VB> say in the documentation that they do the same and that
> VB> verify-hostname-error will be removed at some point?
>
> I think :verify-error should be a list; when it contains 'x509-hostname
> then we behave like :verify-hostname-error does now, for backwards
> compatibility.  But otherwise we'll add extra checks to the list, not as
> top-level options to `gnutls-boot'.  It's easy to put a Customize
> interface on top of that.

When you say x509-hostname, do you mean "by default"? If yes, I
agree. But I suppose you would have to implement a "confirm on error"
option. I cannot propose myself to implement that since I have
absolutely no clue on how Emacs Lisp interface with C.
-- 
Indent to show the logical structure of a program.
            - The Elements of Programming Style (Kernighan & Plauger)

Re: Builtin GnuTLS support and certificate verification

[Ted Zlatanov]

On Mon, 04 Nov 2013 23:38:50 +0100 Vincent Bernat <bernat@luffy.cx> wrote: 

VB>  ❦  4 novembre 2013 22:10 CET, Ted Zlatanov <tzz@lifelogs.com> :
VB> So, for me, there should be only one verification algorithm. We are not
VB> in the ideal case for this because we only have one algorithm but its
VB> name does not exactly describe it.
>> 
VB> Maybe you could just alias verify-error and verify-hostname-error and
VB> say in the documentation that they do the same and that
VB> verify-hostname-error will be removed at some point?
>> 
>> I think :verify-error should be a list; when it contains 'x509-hostname
>> then we behave like :verify-hostname-error does now, for backwards
>> compatibility.  But otherwise we'll add extra checks to the list, not as
>> top-level options to `gnutls-boot'.  It's easy to put a Customize
>> interface on top of that.

VB> When you say x509-hostname, do you mean "by default"? If yes, I
VB> agree.

Yes.  I think.  How would you like it to look?

VB> But I suppose you would have to implement a "confirm on error"
VB> option. I cannot propose myself to implement that since I have
VB> absolutely no clue on how Emacs Lisp interface with C.

I'm interested in your opinion.  How would you expect Emacs (on the
GnuTLS C level or on the Gnus level) to handle these cases, and how
would you control them with customizable variables?

- expired cert
- hostname mismatch
- self-signed cert, first time seen
- cert mismatch

In general we have the problem of asking questions in the middle of
establishing a network connection.  This is not easy with Emacs, whose
interactive ELisp layer is too complicated to be reliably called from
the C layer.  So all of the above have to work without user interaction.

Ted

Re: Builtin GnuTLS support and certificate verification

[Vincent Bernat]

 ❦ 11 novembre 2013 16:45 CET, Ted Zlatanov <tzz@lifelogs.com> :

> VB> But I suppose you would have to implement a "confirm on error"
> VB> option. I cannot propose myself to implement that since I have
> VB> absolutely no clue on how Emacs Lisp interface with C.
>
> I'm interested in your opinion.  How would you expect Emacs (on the
> GnuTLS C level or on the Gnus level) to handle these cases, and how
> would you control them with customizable variables?
>
> - expired cert
> - hostname mismatch
> - self-signed cert, first time seen
> - cert mismatch
>
> In general we have the problem of asking questions in the middle of
> establishing a network connection.  This is not easy with Emacs, whose
> interactive ELisp layer is too complicated to be reliably called from
> the C layer.  So all of the above have to work without user
> interaction.

Not being able to interact with the user is not a big problem I think:
we can still output messages to tell her what to do, right?

By default, I would see that all checks are enabled by default: the
certificate has not expired, the hostname matches and the certificate is
signed by a known authority (certificates in `gnutls-trustfiles`).

When something goes wrong, we get a buffer with the certificate in
"clear text" (like openssl x509 -in ... -noout -text). If needed, this
is something that I can dig and provide C code for GNU TLS. This output
contains the certificate fingerprint.

A user has the possibility to whitelist the fingerprint and bypass any
test. We should have both `gnutls-whitelist-certificates` variable and
an option to override this whitelist when using gnutls-negotiate. The
rationale is that we can't expect all gnutls-negotiate users to
implement whitelisting.

I think that whitelisting by fingerprint is an improvement over what is
currently done by browsers which whitelist a whole domain without
pinning the certificate.

In the same way as for whitelisting, default verification options should
be a variable with possibility to override it by using the appropriate
option of `gnutls-negotiate`.

Verification options could be:

 - `expired-certificate`
 - `revoked-certificate`
 - `untrusted-certificate`
 - `hostname-mismatch`
-- 
Let the machine do the dirty work.
            - The Elements of Programming Style (Kernighan & Plauger)

Re: Builtin GnuTLS support and certificate verification

[Julien Danjou]

[-- Attachment #1: Type: text/plain, Size: 1696 bytes --]

On Sat, Nov 16 2013, Vincent Bernat wrote:

> By default, I would see that all checks are enabled by default: the
> certificate has not expired, the hostname matches and the certificate is
> signed by a known authority (certificates in `gnutls-trustfiles`).

+1

> When something goes wrong, we get a buffer with the certificate in
> "clear text" (like openssl x509 -in ... -noout -text). If needed, this
> is something that I can dig and provide C code for GNU TLS. This output
> contains the certificate fingerprint.
>
> A user has the possibility to whitelist the fingerprint and bypass any
> test. We should have both `gnutls-whitelist-certificates` variable and
> an option to override this whitelist when using gnutls-negotiate. The
> rationale is that we can't expect all gnutls-negotiate users to
> implement whitelisting.
>
> I think that whitelisting by fingerprint is an improvement over what is
> currently done by browsers which whitelist a whole domain without
> pinning the certificate.
>
> In the same way as for whitelisting, default verification options should
> be a variable with possibility to override it by using the appropriate
> option of `gnutls-negotiate`.
>
> Verification options could be:
>
>  - `expired-certificate`
>  - `revoked-certificate`
>  - `untrusted-certificate`
>  - `hostname-mismatch`

I think this is a really good idea and I'm waiting for that for a long
time. Since I don't have time to do this myself currently, consider this
message as a strong support. \o/

I'd be happy to help and test as far as I can.

-- 
Julien Danjou
-- Free Software hacker - independent consultant
-- http://julien.danjou.info

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 835 bytes --]

Re: Builtin GnuTLS support and certificate verification

[Ted Zlatanov]

[-- Attachment #1: Type: text/plain, Size: 2723 bytes --]

On Sat, 16 Nov 2013 14:11:33 +0100 Julien Danjou <julien@danjou.info> wrote: 

JD> On Sat, Nov 16 2013, Vincent Bernat wrote:
>> In the same way as for whitelisting, default verification options should
>> be a variable with possibility to override it by using the appropriate
>> option of `gnutls-negotiate`.

OK, I worked on this.

>> Verification options could be:
>> 
>> - `expired-certificate`
>> - `revoked-certificate`
>> - `untrusted-certificate`
>> - `hostname-mismatch`

I'm not sure this granularity is necessary.  I just have :trustfiles and
:hostname as options right now.  Anyone else with an opinion?  Note that
you can also specify verification flags.  From the `gnutls-boot' docs:

VERIFY-FLAGS is a numeric OR of verification flags only for
`gnutls-x509pki' connections.  See GnuTLS' x509.h for details;
here's a recent version of the list.

    GNUTLS_VERIFY_DISABLE_CA_SIGN = 1,
    GNUTLS_VERIFY_ALLOW_X509_V1_CA_CRT = 2,
    GNUTLS_VERIFY_DO_NOT_ALLOW_SAME = 4,
    GNUTLS_VERIFY_ALLOW_ANY_X509_V1_CA_CRT = 8,
    GNUTLS_VERIFY_ALLOW_SIGN_RSA_MD2 = 16,
    GNUTLS_VERIFY_ALLOW_SIGN_RSA_MD5 = 32,
    GNUTLS_VERIFY_DISABLE_TIME_CHECKS = 64,
    GNUTLS_VERIFY_DISABLE_TRUSTED_TIME_CHECKS = 128,
    GNUTLS_VERIFY_DO_NOT_ALLOW_X509_V1_CA_CRT = 256

It must be omitted, a number, or nil; if omitted or nil it
defaults to GNUTLS_VERIFY_ALLOW_X509_V1_CA_CRT.

JD> I think this is a really good idea and I'm waiting for that for a long
JD> time. Since I don't have time to do this myself currently, consider this
JD> message as a strong support. \o/

JD> I'd be happy to help and test as far as I can.

First patch attached here against Emacs trunk.  It removes
`:verify-hostname-error' everywhere, adds a new `gnutls-verify-error'
defcustom and uses it in `gnutls-boot', and allows the user to match the
hostname to a regexp and provide verification flags for each such
regexp.

To make verification errors abort GnuTLS negotiations, the
`gnutls-verify-error' simply needs to be t (it's nil in this patch).

My concern is that suddenly connections will start failing for our users
and bug reports will flow, and I don't have time to explain to everyone
why their self-signed certificates need exceptions.  This can be really,
really annoying.  But logging in *Messages* is not very useful either,
users don't read it.  So what's the right thing?  How about a default
behavior of flashing a warning, then sit-for 3 seconds?  A hard error
can be optional but not the default.

I'm also not sure I like the look and feel of the `gnutls-verify-error'
defcustom.  It's kind of awkward.

I'd like to get this done before the Emacs code freeze next week or so.
Please give me your opinions and test the code.

Ted


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: gnutls-verify-error.patch --]
[-- Type: text/x-diff, Size: 8558 bytes --]

=== modified file 'lisp/net/gnutls.el'
--- lisp/net/gnutls.el	2013-09-18 04:50:54 +0000
+++ lisp/net/gnutls.el	2013-12-08 04:00:04 +0000
@@ -51,6 +51,19 @@
   :type '(choice (const nil)
                  string))
 
+(defcustom gnutls-verify-error nil
+  "If non-nil, this should be a list of checks per hostname regex or t."
+  :group 'gnutls
+  :type '(choice
+          (const t)
+          (repeat :tag "List of hostname regexps with flags for each"
+           (list
+            (choice :tag "Hostname"
+                    (const ".*" :tag "Any hostname")
+                    regexp)
+            (set (const :trustfiles)
+                 (const :hostname))))))
+
 (defcustom gnutls-trustfiles
   '(
     "/etc/ssl/certs/ca-certificates.crt" ; Debian, Ubuntu, Gentoo and Arch Linux
@@ -138,19 +151,25 @@
 \(see `gnutls-min-prime-bits' for more information).  Use nil for the
 default.
 
-When VERIFY-HOSTNAME-ERROR is not nil, an error will be raised
-when the hostname does not match the presented certificate's host
-name.  The exact verification algorithm is a basic implementation
-of the matching described in RFC2818 (HTTPS), which takes into
-account wildcards, and the DNSName/IPAddress subject alternative
-name PKIX extension.  See GnuTLS' gnutls_x509_crt_check_hostname
-for details.  When VERIFY-HOSTNAME-ERROR is nil, only a warning
-will be issued.
-
-When VERIFY-ERROR is not nil, an error will be raised when the
-peer certificate verification fails as per GnuTLS'
-gnutls_certificate_verify_peers2.  Otherwise, only warnings will
-be shown about the verification failure.
+VERIFY-HOSTNAME-ERROR is a backwards compatibility option for
+putting `:hostname' in VERIFY-ERROR.
+
+When VERIFY-ERROR is t or a list containing `:trustfiles', an
+error will be raised when the peer certificate verification fails
+as per GnuTLS' gnutls_certificate_verify_peers2.  Otherwise, only
+warnings will be shown about the verification failure.
+
+When VERIFY-ERROR is t or a list containing `:hostname', an error
+will be raised when the hostname does not match the presented
+certificate's host name.  The exact verification algorithm is a
+basic implementation of the matching described in
+RFC2818 (HTTPS), which takes into account wildcards, and the
+DNSName/IPAddress subject alternative name PKIX extension.  See
+GnuTLS' gnutls_x509_crt_check_hostname for details.  Otherwise,
+only a warning will be issued.
+
+Note that the list in `gnutls-verify-error', matched against the
+HOSTNAME, is the default VERIFY-ERROR.
 
 VERIFY-FLAGS is a numeric OR of verification flags only for
 `gnutls-x509pki' connections.  See GnuTLS' x509.h for details;
@@ -183,8 +202,28 @@
                                 (if gnutls-algorithm-priority
                                     (upcase gnutls-algorithm-priority)
                                   "NORMAL")))))
+         (verify-error (or verify-error
+                           ;; this uses the value of `gnutls-verify-error'
+                           (cond
+                            ;; if t, pass it on
+                            ((eq gnutls-verify-error t)
+                             t)
+                            ;; if a list, look for hostname matches
+                            ((listp gnutls-verify-error)
+                             (mapcan
+                              (lambda (check)
+                                (when (string-match (car check) hostname)
+                                  (cdr check)))
+                              gnutls-verify-error))
+                            ;; else it's nil
+                            (t nil))))
          (min-prime-bits (or min-prime-bits gnutls-min-prime-bits))
-         (params `(:priority ,priority-string
+         params ret)
+
+    (when verify-hostname-error
+      (push :hostname verify-error))
+
+    (setq params `(:priority ,priority-string
                              :hostname ,hostname
                              :loglevel ,gnutls-log-level
                              :min-prime-bits ,min-prime-bits
@@ -193,9 +232,7 @@
                              :keylist ,keylist
                              :verify-flags ,verify-flags
                              :verify-error ,verify-error
-                             :verify-hostname-error ,verify-hostname-error
                              :callbacks nil))
-         ret)
 
     (gnutls-message-maybe
      (setq ret (gnutls-boot process type params))

=== modified file 'src/gnutls.c'
--- src/gnutls.c	2013-11-30 13:31:39 +0000
+++ src/gnutls.c	2013-12-08 04:10:44 +0000
@@ -49,7 +49,7 @@
 static Lisp_Object QCgnutls_bootprop_hostname;
 static Lisp_Object QCgnutls_bootprop_min_prime_bits;
 static Lisp_Object QCgnutls_bootprop_verify_flags;
-static Lisp_Object QCgnutls_bootprop_verify_hostname_error;
+static Lisp_Object QCgnutls_bootprop_verify_error;
 
 /* Callback keys for `gnutls-boot'.  Unused currently.  */
 static Lisp_Object QCgnutls_bootprop_callbacks_verify;
@@ -753,8 +753,12 @@
 :verify-flags is a bitset as per GnuTLS'
 gnutls_certificate_set_verify_flags.
 
-:verify-hostname-error, if non-nil, makes a hostname mismatch an
-error.  Otherwise it will be just a warning.
+:verify-hostname-error is ignored.  Pass :hostname in :verify-error
+instead.
+
+:verify-error is a list of symbols to express verification checks or
+`t' to do all checks.  Currently it can contain `:trustfiles' and
+`:hostname' to verify the certificate or the hostname respectively.
 
 :min-prime-bits is the minimum accepted number of bits the client will
 accept in Diffie-Hellman key exchange.
@@ -798,8 +802,7 @@
   /* Lisp_Object callbacks; */
   Lisp_Object loglevel;
   Lisp_Object hostname;
-  /* Lisp_Object verify_error; */
-  Lisp_Object verify_hostname_error;
+  Lisp_Object verify_error;
   Lisp_Object prime_bits;
 
   CHECK_PROCESS (proc);
@@ -818,11 +821,14 @@
   keylist               = Fplist_get (proplist, QCgnutls_bootprop_keylist);
   crlfiles              = Fplist_get (proplist, QCgnutls_bootprop_crlfiles);
   loglevel              = Fplist_get (proplist, QCgnutls_bootprop_loglevel);
-  verify_hostname_error = Fplist_get (proplist, QCgnutls_bootprop_verify_hostname_error);
+  verify_error          = Fplist_get (proplist, QCgnutls_bootprop_verify_error);
   prime_bits            = Fplist_get (proplist, QCgnutls_bootprop_min_prime_bits);
 
+  if (!Flistp (verify_error))
+    error ("gnutls-boot: invalid :verify_error parameter (not a list)");
+
   if (!STRINGP (hostname))
-    error ("gnutls-boot: invalid :hostname parameter");
+    error ("gnutls-boot: invalid :hostname parameter (not a string)");
   c_hostname = SSDATA (hostname);
 
   state = XPROCESS (proc)->gnutls_state;
@@ -1047,14 +1053,17 @@
 
   if (peer_verification != 0)
     {
-      if (NILP (verify_hostname_error))
-	GNUTLS_LOG2 (1, max_log_level, "certificate validation failed:",
-		     c_hostname);
-      else
-	{
+      if (EQ (verify_error, Qt)
+          || !NILP (Fmember (QCgnutls_bootprop_trustfiles, verify_error)))
+        {
 	  emacs_gnutls_deinit (proc);
 	  error ("Certificate validation failed %s, verification code %d",
 		 c_hostname, peer_verification);
+        }
+      else
+	{
+          GNUTLS_LOG2 (1, max_log_level, "certificate validation failed:",
+                       c_hostname);
 	}
     }
 
@@ -1094,14 +1103,17 @@
 
       if (!fn_gnutls_x509_crt_check_hostname (gnutls_verify_cert, c_hostname))
 	{
-	  if (NILP (verify_hostname_error))
-	    GNUTLS_LOG2 (1, max_log_level, "x509 certificate does not match:",
-			 c_hostname);
-	  else
-	    {
+          if (EQ (verify_error, Qt)
+              || !NILP (Fmember (QCgnutls_bootprop_hostname, verify_error)))
+            {
 	      fn_gnutls_x509_crt_deinit (gnutls_verify_cert);
 	      emacs_gnutls_deinit (proc);
 	      error ("The x509 certificate does not match \"%s\"", c_hostname);
+            }
+	  else
+	    {
+              GNUTLS_LOG2 (1, max_log_level, "x509 certificate does not match:",
+                           c_hostname);
 	    }
 	}
       fn_gnutls_x509_crt_deinit (gnutls_verify_cert);
@@ -1161,7 +1173,7 @@
   DEFSYM (QCgnutls_bootprop_min_prime_bits, ":min-prime-bits");
   DEFSYM (QCgnutls_bootprop_loglevel, ":loglevel");
   DEFSYM (QCgnutls_bootprop_verify_flags, ":verify-flags");
-  DEFSYM (QCgnutls_bootprop_verify_hostname_error, ":verify-hostname-error");
+  DEFSYM (QCgnutls_bootprop_verify_error, ":verify-error");
 
   DEFSYM (Qgnutls_e_interrupted, "gnutls-e-interrupted");
   Fput (Qgnutls_e_interrupted, Qgnutls_code,

Re: Builtin GnuTLS support and certificate verification

[Vincent Bernat]

 ❦  8 décembre 2013 05:22 CET, Ted Zlatanov <tzz@lifelogs.com> :

>>> Verification options could be:
>>> 
>>> - `expired-certificate`
>>> - `revoked-certificate`
>>> - `untrusted-certificate`
>>> - `hostname-mismatch`
>
> I'm not sure this granularity is necessary.  I just have :trustfiles and
> :hostname as options right now.  Anyone else with an opinion?

I thought you wanted something granular, hence the proposition. I don't
know of any other software proposing granular verification. So, no
problem with dropping this.

> My concern is that suddenly connections will start failing for our users
> and bug reports will flow, and I don't have time to explain to everyone
> why their self-signed certificates need exceptions.  This can be really,
> really annoying.  But logging in *Messages* is not very useful either,
> users don't read it.  So what's the right thing?  How about a default
> behavior of flashing a warning, then sit-for 3 seconds?  A hard error
> can be optional but not the default.

For a first release, just default to the previous behaviour. However,
some day, it would be nice to be "secure by default".

> I'm also not sure I like the look and feel of the `gnutls-verify-error'
> defcustom.  It's kind of awkward.

I am don't know defcustom enough to know if this would give something
like this:

'((".*\\.internal" :hostname)
  (".*" :trustfiles :hostname))

If yes, this seems fine for me. Just add the possible values for tags in
the document string.

> I'd like to get this done before the Emacs code freeze next week or so.
> Please give me your opinions and test the code.

I'll try to test later this day.
-- 
panic("aha1740.c"); /* Goodbye */
	2.2.16 /usr/src/linux/drivers/scsi/aha1740.c

Re: Builtin GnuTLS support and certificate verification

[Ted Zlatanov]

[-- Attachment #1: Type: text/plain, Size: 2662 bytes --]

On Sun, 08 Dec 2013 09:39:23 +0100 Vincent Bernat <bernat@luffy.cx> wrote: 

VB>  ❦  8 décembre 2013 05:22 CET, Ted Zlatanov <tzz@lifelogs.com> :
>>>> Verification options could be:
>>>> 
>>>> - `expired-certificate`
>>>> - `revoked-certificate`
>>>> - `untrusted-certificate`
>>>> - `hostname-mismatch`
>> 
>> I'm not sure this granularity is necessary.  I just have :trustfiles and
>> :hostname as options right now.  Anyone else with an opinion?

VB> I thought you wanted something granular, hence the proposition. I don't
VB> know of any other software proposing granular verification. So, no
VB> problem with dropping this.

Yeah, I went back and forth.  I think two (:trustfiles and :hostname)
verification options is the right balance for now.  I couldn't think of
any cases where I'd want more granularity, but that's why I'm asking :)

>> My concern is that suddenly connections will start failing for our users
>> and bug reports will flow, and I don't have time to explain to everyone
>> why their self-signed certificates need exceptions.  This can be really,
>> really annoying.  But logging in *Messages* is not very useful either,
>> users don't read it.  So what's the right thing?  How about a default
>> behavior of flashing a warning, then sit-for 3 seconds?  A hard error
>> can be optional but not the default.

VB> For a first release, just default to the previous behaviour. However,
VB> some day, it would be nice to be "secure by default".

http://debbugs.gnu.org/13374 and other related bugs are about enabling
"secure by default" and I would like to make that change now, before the
Emacs code freeze.

It feels like the sit-for option is safest.  It preserves the current
behavior while forcing the user to notice something's wrong.  In the
next release, based on user feedback, we can turn verify-error on.  If
no one disagrees, I will implement it on top of the patch attached here.

>> I'm also not sure I like the look and feel of the `gnutls-verify-error'
>> defcustom.  It's kind of awkward.

VB> I am don't know defcustom enough to know if this would give something
VB> like this:

VB> '((".*\\.internal" :hostname)
VB>   (".*" :trustfiles :hostname))

VB> If yes, this seems fine for me. Just add the possible values for tags in
VB> the document string.

Yes, except the cdr is a nested list because I use the "set"
customization type.  So it's '((".*" (:hostname :trustfiles)))

>> I'd like to get this done before the Emacs code freeze next week or so.
>> Please give me your opinions and test the code.

VB> I'll try to test later this day.

Thanks.  Posting patch to emacs-devel as well for review and feedback.

Ted


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: gnutls-verify-error.patch --]
[-- Type: text/x-diff, Size: 8558 bytes --]

=== modified file 'lisp/net/gnutls.el'
--- lisp/net/gnutls.el	2013-09-18 04:50:54 +0000
+++ lisp/net/gnutls.el	2013-12-08 04:00:04 +0000
@@ -51,6 +51,19 @@
   :type '(choice (const nil)
                  string))
 
+(defcustom gnutls-verify-error nil
+  "If non-nil, this should be a list of checks per hostname regex or t."
+  :group 'gnutls
+  :type '(choice
+          (const t)
+          (repeat :tag "List of hostname regexps with flags for each"
+           (list
+            (choice :tag "Hostname"
+                    (const ".*" :tag "Any hostname")
+                    regexp)
+            (set (const :trustfiles)
+                 (const :hostname))))))
+
 (defcustom gnutls-trustfiles
   '(
     "/etc/ssl/certs/ca-certificates.crt" ; Debian, Ubuntu, Gentoo and Arch Linux
@@ -138,19 +151,25 @@
 \(see `gnutls-min-prime-bits' for more information).  Use nil for the
 default.
 
-When VERIFY-HOSTNAME-ERROR is not nil, an error will be raised
-when the hostname does not match the presented certificate's host
-name.  The exact verification algorithm is a basic implementation
-of the matching described in RFC2818 (HTTPS), which takes into
-account wildcards, and the DNSName/IPAddress subject alternative
-name PKIX extension.  See GnuTLS' gnutls_x509_crt_check_hostname
-for details.  When VERIFY-HOSTNAME-ERROR is nil, only a warning
-will be issued.
-
-When VERIFY-ERROR is not nil, an error will be raised when the
-peer certificate verification fails as per GnuTLS'
-gnutls_certificate_verify_peers2.  Otherwise, only warnings will
-be shown about the verification failure.
+VERIFY-HOSTNAME-ERROR is a backwards compatibility option for
+putting `:hostname' in VERIFY-ERROR.
+
+When VERIFY-ERROR is t or a list containing `:trustfiles', an
+error will be raised when the peer certificate verification fails
+as per GnuTLS' gnutls_certificate_verify_peers2.  Otherwise, only
+warnings will be shown about the verification failure.
+
+When VERIFY-ERROR is t or a list containing `:hostname', an error
+will be raised when the hostname does not match the presented
+certificate's host name.  The exact verification algorithm is a
+basic implementation of the matching described in
+RFC2818 (HTTPS), which takes into account wildcards, and the
+DNSName/IPAddress subject alternative name PKIX extension.  See
+GnuTLS' gnutls_x509_crt_check_hostname for details.  Otherwise,
+only a warning will be issued.
+
+Note that the list in `gnutls-verify-error', matched against the
+HOSTNAME, is the default VERIFY-ERROR.
 
 VERIFY-FLAGS is a numeric OR of verification flags only for
 `gnutls-x509pki' connections.  See GnuTLS' x509.h for details;
@@ -183,8 +202,28 @@
                                 (if gnutls-algorithm-priority
                                     (upcase gnutls-algorithm-priority)
                                   "NORMAL")))))
+         (verify-error (or verify-error
+                           ;; this uses the value of `gnutls-verify-error'
+                           (cond
+                            ;; if t, pass it on
+                            ((eq gnutls-verify-error t)
+                             t)
+                            ;; if a list, look for hostname matches
+                            ((listp gnutls-verify-error)
+                             (mapcan
+                              (lambda (check)
+                                (when (string-match (car check) hostname)
+                                  (cdr check)))
+                              gnutls-verify-error))
+                            ;; else it's nil
+                            (t nil))))
          (min-prime-bits (or min-prime-bits gnutls-min-prime-bits))
-         (params `(:priority ,priority-string
+         params ret)
+
+    (when verify-hostname-error
+      (push :hostname verify-error))
+
+    (setq params `(:priority ,priority-string
                              :hostname ,hostname
                              :loglevel ,gnutls-log-level
                              :min-prime-bits ,min-prime-bits
@@ -193,9 +232,7 @@
                              :keylist ,keylist
                              :verify-flags ,verify-flags
                              :verify-error ,verify-error
-                             :verify-hostname-error ,verify-hostname-error
                              :callbacks nil))
-         ret)
 
     (gnutls-message-maybe
      (setq ret (gnutls-boot process type params))

=== modified file 'src/gnutls.c'
--- src/gnutls.c	2013-11-30 13:31:39 +0000
+++ src/gnutls.c	2013-12-08 04:10:44 +0000
@@ -49,7 +49,7 @@
 static Lisp_Object QCgnutls_bootprop_hostname;
 static Lisp_Object QCgnutls_bootprop_min_prime_bits;
 static Lisp_Object QCgnutls_bootprop_verify_flags;
-static Lisp_Object QCgnutls_bootprop_verify_hostname_error;
+static Lisp_Object QCgnutls_bootprop_verify_error;
 
 /* Callback keys for `gnutls-boot'.  Unused currently.  */
 static Lisp_Object QCgnutls_bootprop_callbacks_verify;
@@ -753,8 +753,12 @@
 :verify-flags is a bitset as per GnuTLS'
 gnutls_certificate_set_verify_flags.
 
-:verify-hostname-error, if non-nil, makes a hostname mismatch an
-error.  Otherwise it will be just a warning.
+:verify-hostname-error is ignored.  Pass :hostname in :verify-error
+instead.
+
+:verify-error is a list of symbols to express verification checks or
+`t' to do all checks.  Currently it can contain `:trustfiles' and
+`:hostname' to verify the certificate or the hostname respectively.
 
 :min-prime-bits is the minimum accepted number of bits the client will
 accept in Diffie-Hellman key exchange.
@@ -798,8 +802,7 @@
   /* Lisp_Object callbacks; */
   Lisp_Object loglevel;
   Lisp_Object hostname;
-  /* Lisp_Object verify_error; */
-  Lisp_Object verify_hostname_error;
+  Lisp_Object verify_error;
   Lisp_Object prime_bits;
 
   CHECK_PROCESS (proc);
@@ -818,11 +821,14 @@
   keylist               = Fplist_get (proplist, QCgnutls_bootprop_keylist);
   crlfiles              = Fplist_get (proplist, QCgnutls_bootprop_crlfiles);
   loglevel              = Fplist_get (proplist, QCgnutls_bootprop_loglevel);
-  verify_hostname_error = Fplist_get (proplist, QCgnutls_bootprop_verify_hostname_error);
+  verify_error          = Fplist_get (proplist, QCgnutls_bootprop_verify_error);
   prime_bits            = Fplist_get (proplist, QCgnutls_bootprop_min_prime_bits);
 
+  if (!Flistp (verify_error))
+    error ("gnutls-boot: invalid :verify_error parameter (not a list)");
+
   if (!STRINGP (hostname))
-    error ("gnutls-boot: invalid :hostname parameter");
+    error ("gnutls-boot: invalid :hostname parameter (not a string)");
   c_hostname = SSDATA (hostname);
 
   state = XPROCESS (proc)->gnutls_state;
@@ -1047,14 +1053,17 @@
 
   if (peer_verification != 0)
     {
-      if (NILP (verify_hostname_error))
-	GNUTLS_LOG2 (1, max_log_level, "certificate validation failed:",
-		     c_hostname);
-      else
-	{
+      if (EQ (verify_error, Qt)
+          || !NILP (Fmember (QCgnutls_bootprop_trustfiles, verify_error)))
+        {
 	  emacs_gnutls_deinit (proc);
 	  error ("Certificate validation failed %s, verification code %d",
 		 c_hostname, peer_verification);
+        }
+      else
+	{
+          GNUTLS_LOG2 (1, max_log_level, "certificate validation failed:",
+                       c_hostname);
 	}
     }
 
@@ -1094,14 +1103,17 @@
 
       if (!fn_gnutls_x509_crt_check_hostname (gnutls_verify_cert, c_hostname))
 	{
-	  if (NILP (verify_hostname_error))
-	    GNUTLS_LOG2 (1, max_log_level, "x509 certificate does not match:",
-			 c_hostname);
-	  else
-	    {
+          if (EQ (verify_error, Qt)
+              || !NILP (Fmember (QCgnutls_bootprop_hostname, verify_error)))
+            {
 	      fn_gnutls_x509_crt_deinit (gnutls_verify_cert);
 	      emacs_gnutls_deinit (proc);
 	      error ("The x509 certificate does not match \"%s\"", c_hostname);
+            }
+	  else
+	    {
+              GNUTLS_LOG2 (1, max_log_level, "x509 certificate does not match:",
+                           c_hostname);
 	    }
 	}
       fn_gnutls_x509_crt_deinit (gnutls_verify_cert);
@@ -1161,7 +1173,7 @@
   DEFSYM (QCgnutls_bootprop_min_prime_bits, ":min-prime-bits");
   DEFSYM (QCgnutls_bootprop_loglevel, ":loglevel");
   DEFSYM (QCgnutls_bootprop_verify_flags, ":verify-flags");
-  DEFSYM (QCgnutls_bootprop_verify_hostname_error, ":verify-hostname-error");
+  DEFSYM (QCgnutls_bootprop_verify_error, ":verify-error");
 
   DEFSYM (Qgnutls_e_interrupted, "gnutls-e-interrupted");
   Fput (Qgnutls_e_interrupted, Qgnutls_code,

Re: Builtin GnuTLS support and certificate verification

[Ted Zlatanov]

I pushed this work to the Emacs trunk with the old behavior (connections
never abort, just warn).  Please customize `gnutls-verify-error' to get
the new behavior, erroring out on validation failures.  I encourage you
to try it and report any issues.

Ted

Re: Builtin GnuTLS support and certificate verification

[Katsumi Yamaoka]

Ted Zlatanov wrote:
> I pushed this work to the Emacs trunk with the old behavior (connections
> never abort, just warn).  Please customize `gnutls-verify-error' to get
> the new behavior, erroring out on validation failures.  I encourage you
> to try it and report any issues.

One of my POP mail sources got to not work for today's Emacs build
from the trunk.

First, `mapcan' that `gnutls-negotiate' uses is a cl run-time
function, so I needed to load cl manually.

If `gnutls-verify-error' is nil, `mail-source-fetch-pop' fails
for the error: (wrong-type-argument listp nil)
This is what the built-in function `gnutls-boot' issues.
The arguments passed to it then are:
#<prosess POP>
gnutls-x509pki
(:priority "NORMAL" :hostname "my.pop.server" :loglevel 0
 :min-prime-bits 1024 :trustfiles ("/usr/ssl/certs/ca-bundle.crt")
 :crlfiles nil :keylist nil :verify-flags nil :verify-error nil
 :callbacks nil)

If I set `gnutls-verify-error' to t, `gnutls-boot' issues the error
(wrong-type-argument listp t) because :verify-error is t.

The mail-source for this case is:

(pop :server "my.pop.server"
     :user "User Name"
     :password "Password"
     :leave 7)

Server's response is:

+OK Dovecot ready.^M
+OK^M
CAPA^M
TOP^M
UIDL^M
RESP-CODES^M
PIPELINING^M
STLS^M
USER^M
SASL PLAIN LOGIN^M
.^M
+OK Begin TLS negotiation now.^M

And a workaround to make it work is:

(defadvice open-network-stream (before
				never-use-stls
				(name buffer host service &rest parameters)
				activate)
  "Never use starttls."
  (when (member name '("nntpd" "POP"))
    (setq parameters (copy-sequence parameters))
    (plist-put parameters :starttls-function nil)))

Thanks.

Re: Builtin GnuTLS support and certificate verification

[Herbert J. Skuhra]

ma. 16. des. 2013 kl. 02.39 +0100 skrev Katsumi Yamaoka:

> Ted Zlatanov wrote:
>> I pushed this work to the Emacs trunk with the old behavior (connections
>> never abort, just warn).  Please customize `gnutls-verify-error' to get
>> the new behavior, erroring out on validation failures.  I encourage you
>> to try it and report any issues.
>
> One of my POP mail sources got to not work for today's Emacs build
> from the trunk.

Here Wanderlust and Gnus only connect (imaps) when I revert r115532  
(src/gnutls.c).
Maybe a different issue...

-- 
Herbert

Re: Builtin GnuTLS support and certificate verification

[Tassilo Horn]

"Herbert J. Skuhra" <hskuhra@eumx.net> writes:

>>> I pushed this work to the Emacs trunk with the old behavior (connections
>>> never abort, just warn).  Please customize `gnutls-verify-error' to get
>>> the new behavior, erroring out on validation failures.  I encourage you
>>> to try it and report any issues.
>>
>> One of my POP mail sources got to not work for today's Emacs build
>> from the trunk.
>
> Here Wanderlust and Gnus only connect (imaps) when I revert r115532
> (src/gnutls.c).
> Maybe a different issue...

I guess that's bug#16161 which I'm also suffering from.

  http://debbugs.gnu.org/cgi/bugreport.cgi?bug=16161

Bye,
Tassilo

Re: Builtin GnuTLS support and certificate verification

[Ted Zlatanov]

On Mon, 16 Dec 2013 06:31:16 +0000 "Herbert J. Skuhra" <hskuhra@eumx.net> wrote: 

HJS> ma. 16. des. 2013 kl. 02.39 +0100 skrev Katsumi Yamaoka:

>> Ted Zlatanov wrote:
>>> I pushed this work to the Emacs trunk with the old behavior (connections
>>> never abort, just warn).  Please customize `gnutls-verify-error' to get
>>> the new behavior, erroring out on validation failures.  I encourage you
>>> to try it and report any issues.
>> 
>> One of my POP mail sources got to not work for today's Emacs build
>> from the trunk.

HJS> Here Wanderlust and Gnus only connect (imaps) when I revert r115532
HJS> (src/gnutls.c).
HJS> Maybe a different issue...

These are recent gnutls.c changes by Paul Eggert.  Could you open a
bug report and mention your platform in particular?  I think they are
not related to the certificate validation changes I mentioned.

Ted

Re: Builtin GnuTLS support and certificate verification

[Ted Zlatanov]

On Mon, 16 Dec 2013 14:51:58 +0100 Tassilo Horn <tsdh@gnu.org> wrote: 

TH> "Herbert J. Skuhra" <hskuhra@eumx.net> writes:
>>>> I pushed this work to the Emacs trunk with the old behavior (connections
>>>> never abort, just warn).  Please customize `gnutls-verify-error' to get
>>>> the new behavior, erroring out on validation failures.  I encourage you
>>>> to try it and report any issues.
>>> 
>>> One of my POP mail sources got to not work for today's Emacs build
>>> from the trunk.
>> 
>> Here Wanderlust and Gnus only connect (imaps) when I revert r115532
>> (src/gnutls.c).
>> Maybe a different issue...

TH> I guess that's bug#16161 which I'm also suffering from.

TH>   http://debbugs.gnu.org/cgi/bugreport.cgi?bug=16161

Hmm, OK, maybe it is my fault :)  I'll follow up in the bug report.

Ted

Re: Builtin GnuTLS support and certificate verification

[Ted Zlatanov]

On Mon, 16 Dec 2013 10:39:48 +0900 Katsumi Yamaoka <yamaoka@jpl.org> wrote: 

KY> Ted Zlatanov wrote:
>> I pushed this work to the Emacs trunk with the old behavior (connections
>> never abort, just warn).  Please customize `gnutls-verify-error' to get
>> the new behavior, erroring out on validation failures.  I encourage you
>> to try it and report any issues.

KY> One of my POP mail sources got to not work for today's Emacs build
KY> from the trunk.

KY> First, `mapcan' that `gnutls-negotiate' uses is a cl run-time
KY> function, so I needed to load cl manually.

Ah, yes.  Stefan fixed it already.  Sorry.

KY> If `gnutls-verify-error' is nil, `mail-source-fetch-pop' fails
KY> for the error: (wrong-type-argument listp nil)
KY> This is what the built-in function `gnutls-boot' issues.
KY> The arguments passed to it then are:
KY> #<prosess POP>
KY> gnutls-x509pki
KY> (:priority "NORMAL" :hostname "my.pop.server" :loglevel 0
KY>  :min-prime-bits 1024 :trustfiles ("/usr/ssl/certs/ca-bundle.crt")
KY>  :crlfiles nil :keylist nil :verify-flags nil :verify-error nil
KY>  :callbacks nil)

KY> If I set `gnutls-verify-error' to t, `gnutls-boot' issues the error
KY> (wrong-type-argument listp t) because :verify-error is t.

Looks like http://debbugs.gnu.org/cgi/bugreport.cgi?bug=16161 as well.
I'll follow up.

Ted