[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: |
Lars Ingebrigtsen |
Subject: |
bug#26835: 26.0.50; url-retrieve no longer raises certificate errors |
Date: |
Wed, 10 May 2017 16:24:13 +0200 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/26.0.50 (gnu/linux) |
Eli Zaretskii <eliz@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