bug#45855: 28.0.50; gnus does not start if one of the nntp backend fails to authenticate

bug#45855: 28.0.50; gnus does not start if one of the nntp backend fails to authenticate

[Alexandre Duret-Lutz]

Hi,

I'm using a setup like this:

      (setq gnus-select-method '(nnnil ""))
      (setq gnus-secondary-select-methods
            '((nntp "news.epita.fr")
              (nnmaildir "mymail" (directory "~/.mail/mymail/"))
              (nntp "news.lrde.epita.fr"
                    (nntp-open-connection-function nntp-open-ssl-stream)
                    (nntp-port-number 563)
                    (nntp-address "news.lrde.epita.fr"))
              ))

Two days ago the server news.lrde.epita.fr:563 was badly configured, and
would fail to initiate the TLS connection.   During the startup of Gnus,
I would see a message like

> Warning: Opening nntp server on news.lrde.epita.fr... failed:>>>
> (gnutls-error nntpd<1> gnutls-e-invalid-session);

and then another one (that I have not kept) explaining that Gnus would
simply ignore this server and continue.

This is perfect: I'm told that something is wrong with one backend, but
I can still use the other ones.

Now, today, the TLS settings of news.lrde.epita.fr have been fixed,
however the authentication is still not working on this server.

When I start gnus, I see

> Opening nntp server on news.lrde.epita.fr...done
> Authorization Rejected

and then Gnus simply stops loading, leaving me with its nice logo to
contemplate.  I had to comment out that server from
gnus-secondary-select-methods in order to read my mail.


It seems weird to me that the TLS error is handled as a warning,
but that the authentication error is a hard one.  Would it be possible
to handle both error conditions similarly?  (Preferably disabling
that server in both case.)

Thanks!



In GNU Emacs 28.0.50 (build 2, x86_64-pc-linux-gnu, GTK+ Version 3.24.24, cairo version 1.16.0)
 of 2021-01-10 built on goulash
Repository revision: 5960e9cf5770dab2bd3abfb8640f6553bfa1b190
Repository branch: master
Windowing system distributor 'The X.Org Foundation', version 11.0.12010000
System Description: Debian GNU/Linux bullseye/sid

Configured features:
XPM JPEG TIFF GIF PNG RSVG CAIRO SOUND GPM DBUS GSETTINGS GLIB NOTIFY
INOTIFY ACL LIBSELINUX GNUTLS LIBXML2 FREETYPE HARFBUZZ M17N_FLT LIBOTF
ZLIB TOOLKIT_SCROLL_BARS GTK3 X11 XDBE XIM MODULES THREADS LIBSYSTEMD
JSON PDUMPER LCMS2

Important settings:
  value of $LANG: en_US.UTF-8
  value of $XMODIFIERS: @im=ibus
  locale-coding-system: utf-8-unix

-- 
Alexandre Duret-Lutz

bug#45855: 28.0.50; gnus does not start if one of the nntp backend fails to authenticate

[Lars Ingebrigtsen]

Alexandre Duret-Lutz <adl@lrde.epita.fr> writes:

>> Opening nntp server on news.lrde.epita.fr...done
>> Authorization Rejected
>
> and then Gnus simply stops loading, leaving me with its nice logo to
> contemplate. 

I tried to reproduce this by putting in a wrong password in .authinfo
for news.eternal-september.org and starting Gnus.  I got:

nntp (news.eternal-september.org) open error: ‘481 Invalid credentials ’.  Continue? (y or n) y

Hitting `y' then made Gnus continue (but saying that it's ignoring this
server).

So I'm unable to reproduce this problem.  Does (setq debug-on-error t)
give you a backtrace?

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

bug#45855: 28.0.50; gnus does not start if one of the nntp backend fails to authenticate

[Alexandre Duret-Lutz]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> So I'm unable to reproduce this problem.  Does (setq debug-on-error t)
> give you a backtrace?

Here:

Debugger entered--Lisp error: (nntp-authinfo-rejected . "Password rejected")
  signal(nntp-authinfo-rejected "Password rejected")
  #f(compiled-function () #<bytecode -0x100b464ebb0792ba>)()
  nntp-with-open-group-function(nil "news.lrde.epita.fr" nil #f(compiled-function () #<bytecode -0x100b464ebb0792ba>))
  nntp-request-newgroups("Mon, 18 Jan 2021 18:33:40 +0100" "news.lrde.epita.fr")
  gnus-request-newgroups("Mon, 18 Jan 2021 18:33:40 +0100" (nntp "news.lrde.epita.fr" (nntp-open-connection-function nntp-open-ssl-stream) (nntp-port-number 563) (nntp-address "news.lrde.epita.fr")))
  gnus-ask-server-for-new-groups()
  gnus-find-new-newsgroups()
  gnus-setup-news(nil nil nil)
  #f(compiled-function () #<bytecode -0xf05a054e1413c45>)()
  gnus-1(nil nil nil)
  gnus(nil)
  funcall-interactively(gnus nil)
  call-interactively(gnus nil nil)
  command-execute(gnus)



Here is what I see when I do it by hand:

% gnutls-cli -p 563 news.lrde.epita.fr
[...]
200 news.lrde.epita.fr InterNetNews NNRP server INN 2.6.3 ready (no posting)
AUTHINFO USER adl
381 Enter password
AUTHINFO PASS dummy
481 Authentication failed

bug#45855: 28.0.50; gnus does not start if one of the nntp backend fails to authenticate

[Lars Ingebrigtsen]

Alexandre Duret-Lutz <adl@lrde.epita.fr> writes:

> Lars Ingebrigtsen <larsi@gnus.org> writes:
>
>> So I'm unable to reproduce this problem.  Does (setq debug-on-error t)
>> give you a backtrace?
>
> Here:
>
> Debugger entered--Lisp error: (nntp-authinfo-rejected . "Password rejected")
>   signal(nntp-authinfo-rejected "Password rejected")

Thanks.  This error was signalled from a different part of nntp.el than
when I tested with my setup, but using yours, I was able to reproduce
it easily enough.

This should now be fixed in Emacs 28.  The problem seems to be that we
have a special `nntp-authinfo-rejected' error condition that sounds like
it should be used here, but it shouldn't, because that'll make Gnus
startup totally fail, as you say.  Looking at when the error condition
was introduced (in 2015), it was meant for a different case:

       * lisp/gnus/nntp.el (nntp-end-of-line): Doc fix.
       (nntp-authinfo-rejected): New error condition.
       (nntp-wait-for): Use new error condition to signal authentication
       error.
       (nntp-retrieve-data): Rethrow new error condition to break out of
       recursive call to nntp-send-authinfo.

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