GNU bug report logs - #26835
26.0.50; url-retrieve no longer raises certificate errors

Previous Next

Package: emacs;

Reported by: Aaron Jensen <aaronjensen <at> gmail.com>

Date: Mon, 8 May 2017 18:44:01 UTC

Severity: normal

Tags: security

Found in version 26.0.50

Done: Lars Ingebrigtsen <larsi <at> gnus.org>

Bug is archived. No further changes may be made.

Full log


Message #18 received at 26835 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Aaron Jensen <aaronjensen <at> gmail.com>, Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: 26835 <at> debbugs.gnu.org
Subject: Re: bug#26835: 26.0.50;
 url-retrieve no longer raises certificate errors
Date: Tue, 09 May 2017 20:51:48 +0300
[Resending, as I messed up the previous message.  Apologies.]

> From: Aaron Jensen <aaronjensen <at> gmail.com>
> Date: Mon, 8 May 2017 12:44:52 -0700
> Cc: 26835 <at> debbugs.gnu.org
> 
> It repros in `emacs -Q', just set:
> 
> (setq gnutls-verify-error t)
> (url-retrieve-synchronously "https://wrong.host.badssl.com/")
> 
> In Emacs 25.2, this causes an error to be thrown when you use
> url-retrieve, in 26, it silently proceeds.

That's because we now perform GnuTLS negotiation asynchronously,
without blocking.  When the certificate matching fails, gnutls.c
faithfully stores the error message in the process's status by calling
boot_error:

	      boot_error (p, "The x509 certificate does not match \"%s\"",
			  c_hostname);

and boot_error does:

  static void ATTRIBUTE_FORMAT_PRINTF (2, 3)
  boot_error (struct Lisp_Process *p, const char *m, ...)
  {
    va_list ap;
    va_start (ap, m);
    if (p->is_non_blocking_client)
      pset_status (p, list2 (Qfailed, vformat_string (m, ap)));

So the process status becomes the list (failed "error message").  But
when url-retrieve-synchronously accesses the status, by calling
process-status, we do this:

  status = p->status;
  if (CONSP (status))
    status = XCAR (status);

which loses the error message, leaving just 'failed'.  So
url-retrieve-synchronously silently exits, and doesn't even have the
info that could cause it to signal an error.

IOW, the problem is not that the connection proceeds -- it does not.
The problem is that it fails silently without telling the caller what
caused the failure.

I'll CC Lars, who introduced the non-blocking connections.




This bug report was last modified 7 years and 257 days ago.

Previous Next


GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.