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

Previous Next

Full log

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

From: Aaron Jensen <aaronjensen <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 26835 <at> debbugs.gnu.org
Subject: Re: bug#26835: 26.0.50;
 url-retrieve no longer raises certificate errors
Date: Mon, 8 May 2017 12:44:52 -0700

On Mon, May 8, 2017 at 12:04 PM, Eli Zaretskii <eliz <at> gnu.org> wrote:
>> From: Aaron Jensen <aaronjensen <at> gmail.com>
>> Date: Mon, 8 May 2017 11:42:45 -0700
>>
> I seem to be unable to reproduce any of the wrong behavior in the
> current master build.  Could you please provide more details about
> what errors you see and what failures you expected, but didn't see?
>
> In my testing, Emacs asks me whether to continue connecting, when it
> discovers a bad certificate, and it's up to me to decide.  Did it ask
> you, and if it did, what alternative did you select?
>
> Also, did you try all this in "emacs -Q"?  It looks like you did this
> in a customized session (e.g., because in "emacs -Q" there's no 'loop'
> function, which the above snippet uses).  So the problems could have
> something to do with your customizations.

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.

Also, I can confirm that if gnutls-verify-error is nil, it prompts as
you described. I'll leave it as that for now in my config.

Previous Next

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