[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#26835: 26.0.50; url-retrieve no longer raises certificate errors
From: |
Eli Zaretskii |
Subject: |
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@gmail.com>
> Date: Mon, 8 May 2017 12:44:52 -0700
> Cc: 26835@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.