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

Previous Next

Full log

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

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 26835 <at> debbugs.gnu.org, Aaron Jensen <aaronjensen <at> gmail.com>
Subject: Re: bug#26835: 26.0.50;
 url-retrieve no longer raises certificate errors
Date: Wed, 10 May 2017 16:24:13 +0200

Eli Zaretskii <eliz <at> gnu.org> writes:

>> 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.

(As an aside, perhaps url-retrieve-synchronously should be opening the
socket with :nowait nil?)

>   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.

Good analysis.  I'll try to have a look at this soonish (and make it
report the error properly) unless somebody else beats me to it.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Previous Next

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