bug#7808: 23.2; nntp authinfo bug with async gnus

bug#7808: 23.2; nntp authinfo bug with async gnus

[Robert Brown]

[-- Attachment #1: Type: text/plain, Size: 7711 bytes --]

This bug report will be sent to the Free Software Foundation,
not to your local site managers!
Please write in English if possible, because the Emacs maintainers
usually do not have translators to read other languages for them.

Your bug report will be posted to the bug-gnu-emacs@gnu.org mailing list,
and to the gnu.emacs.bug news group.

Please describe exactly what actions triggered the bug
and the precise symptoms of the bug.  If you can, give
a recipe starting from `emacs -Q':

I use GNUS to read Usenet news with the following setting:

(setq gnus-local-domain "bibliotech.com"
      gnus-local-organization "Bibliotech"
      gnus-select-method '(nntp "news.speakeasy.net"))

(setq gnus-article-save-directory (expand-file-name "~/News")
      gnus-asynchronous t        ; fetch articles in the background
      gnus-check-new-news t
      gnus-emphasis-alist '()        ; turn off smiley processing
      gnus-large-newsgroup 500
      gnus-local-timezone "EST"
      gnus-novice-user t
      gnus-read-active-file nil
      gnus-save-all-headers t
      gnus-save-killed-list nil         ; XXXX: will it work?
      gnus-treat-display-smileys nil)

I select a news group in the *Group* buffer, then read a couple of
articles.  Invariably, GNUS hangs with message "Waiting for async
article".  If I evaluate

    (setq nntp-record-commands t)

and modify the nntp-record-command function to print the process name of
the connection it's sending commands to, I see something like this in
the *nntp-log* buffer:

20110108T171746.825 news.speakeasy.net nntpd MODE READER
20110108T171749.813 news.speakeasy.net nntpd NEWGROUPS 110108 212159 GMT
20110108T171749.835 news.speakeasy.net nntpd AUTHINFO USER
bbrown@speakeasy.net
20110108T171749.854 news.speakeasy.net nntpd AUTHINFO PASS XXXXXXXX
20110108T171749.927 news.speakeasy.net nntpd NEWGROUPS 110108 212159 GMT
20110108T171750.459 news.speakeasy.net nntpd LIST ACTIVE rec.woodworking
20110108T171751.079 news.speakeasy.net nntpd LIST ACTIVE rec.woodworking
20110108T171751.080 news.speakeasy.net nntpd LIST ACTIVE gnu.utils.help
20110108T171751.081 news.speakeasy.net nntpd LIST ACTIVE gnu.utils.bugs

...

20110108T171751.088 news.speakeasy.net nntpd LIST ACTIVE
comp.programming.threads
20110108T171751.088 news.speakeasy.net nntpd LIST ACTIVE comp.arch
20110108T171751.089 news.speakeasy.net nntpd LIST ACTIVE comp.ai
20110108T171811.659 news.speakeasy.net nntpd GROUP comp.lang.python
20110108T171826.697 news.speakeasy.net nntpd ARTICLE 714484
20110108T171827.387 news.speakeasy.net nntpd<1> MODE READER
20110108T171827.407 news.speakeasy.net nntpd<1> GROUP comp.lang.python
20110108T171827.408 news.speakeasy.net nntpd<1> ARTICLE 714514
20110108T171827.426 news.speakeasy.net nntpd AUTHINFO USER
bbrown@speakeasy.net
20110108T171827.447 news.speakeasy.net nntpd AUTHINFO PASS XXXXXXXX
20110108T171827.467 news.speakeasy.net nntpd<1> ARTICLE 714514
20110108T171827.485 news.speakeasy.net nntpd AUTHINFO USER
bbrown@speakeasy.net
20110108T171827.504 news.speakeasy.net nntpd AUTHINFO PASS XXXXXXXX
20110108T171827.523 news.speakeasy.net nntpd<1> ARTICLE 714514
20110108T171827.543 news.speakeasy.net nntpd AUTHINFO USER
bbrown@speakeasy.net
20110108T171827.568 news.speakeasy.net nntpd AUTHINFO PASS XXXXXXXX
20110108T171827.586 news.speakeasy.net nntpd<1> ARTICLE 714514
20110108T171827.604 news.speakeasy.net nntpd AUTHINFO USER
bbrown@speakeasy.net
20110108T171827.620 news.speakeasy.net nntpd AUTHINFO PASS XXXXXXXX
20110108T171827.637 news.speakeasy.net nntpd<1> ARTICLE 714514

The code in nntp.el is getting NNTP responses that request authorization
when requesting article 714514 on the second NNTP connection (nntpd<1>),
but it's incorrectly providing authinfo on the first NNTP connection
(nntpd).

There's a workaround.  I can add "force yes" to the entry in ~/.authinfo for
my
news server.  If I do this, the nntp code unconditionally sends authinfo
when making a new connection.  The nntp logging output looks like the
following and async article reading works:


20110108T171354.196 news.speakeasy.net nntpd MODE READER
20110108T171354.236 news.speakeasy.net nntpd AUTHINFO USER
bbrown@speakeasy.net
20110108T171354.254 news.speakeasy.net nntpd AUTHINFO PASS XXXXXXXX
20110108T171356.578 news.speakeasy.net nntpd NEWGROUPS 110108 212159 GMT
20110108T171357.205 news.speakeasy.net nntpd LIST ACTIVE rec.woodworking
20110108T171357.700 news.speakeasy.net nntpd LIST ACTIVE rec.woodworking
20110108T171357.701 news.speakeasy.net nntpd LIST ACTIVE gnu.utils.help

...

20110108T171357.706 news.speakeasy.net nntpd LIST ACTIVE
comp.programming.threads
20110108T171357.706 news.speakeasy.net nntpd LIST ACTIVE comp.arch
20110108T171357.707 news.speakeasy.net nntpd LIST ACTIVE comp.ai
20110108T171424.732 news.speakeasy.net nntpd GROUP comp.lang.python
20110108T171428.314 news.speakeasy.net nntpd XOVER 715333-715335
20110108T171501.534 news.speakeasy.net nntpd ARTICLE 714484
20110108T171503.746 news.speakeasy.net nntpd<1> MODE READER
20110108T171503.769 news.speakeasy.net nntpd<1> AUTHINFO USER
bbrown@speakeasy.net
20110108T171503.790 news.speakeasy.net nntpd<1> AUTHINFO PASS XXXXXXXX
20110108T171503.865 news.speakeasy.net nntpd<1> GROUP comp.lang.python
20110108T171503.866 news.speakeasy.net nntpd<1> ARTICLE 714514
20110108T171504.978 news.speakeasy.net nntpd<1> ARTICLE 714485
20110108T171505.276 news.speakeasy.net nntpd<1> ARTICLE 714496
20110108T171505.883 news.speakeasy.net nntpd<1> ARTICLE 714486
20110108T171506.004 news.speakeasy.net nntpd<1> ARTICLE 714493
20110108T171506.115 news.speakeasy.net nntpd<1> ARTICLE 714495
20110108T171506.535 news.speakeasy.net nntpd<1> ARTICLE 714572

...



If Emacs crashed, and you have the Emacs process in the gdb debugger,
please include the output from the following gdb commands:
    `bt full' and `xbacktrace'.
For information about debugging Emacs, please read the file
/local/software/package/emacs-23.2/share/emacs/23.2/etc/DEBUG.


In GNU Emacs 23.2.1 (i686-pc-linux-gnu)
 of 2010-08-16 on ugg
configured using `configure  '--prefix=/local/software/package/emacs-23.2'
'--without-x''

Important settings:
  value of $LC_ALL: nil
  value of $LC_COLLATE: C
  value of $LC_CTYPE: nil
  value of $LC_MESSAGES: nil
  value of $LC_MONETARY: nil
  value of $LC_NUMERIC: nil
  value of $LC_TIME: C
  value of $LANG: en_US.UTF-8
  value of $XMODIFIERS: nil
  locale-coding-system: utf-8-unix
  default enable-multibyte-characters: t

Major mode: Lisp Interaction

Minor modes in effect:
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t
  line-number-mode: t

Recent input:
ESC [ > 1 ; 2 3 0 5 ; 0 c ESC x r e p o r t TAB RE
T

Recent messages:
("emacs")

Load-path shadows:
None found.

Features:
(shadow sort mail-extr message ecomplete rfc822 mml easymenu mml-sec
password-cache mm-decode mm-bodies mm-encode mailcap mail-parse rfc2231
rfc2047 rfc2045 qp ietf-drums mailabbrev nnheader gnus-util netrc
time-date mm-util mail-prsvr gmm-utils wid-edit mailheader canlock sha1
hex-util hashcash mail-utils warnings emacsbug slime-autoloads cl cl-19
ediff-hook vc-hooks lisp-float-type lisp-mode register page menu-bar
rfn-eshadow timer jit-lock font-lock syntax facemenu font-core frame
cham georgian utf-8-lang misc-lang vietnamese tibetan thai tai-viet lao
korean japanese hebrew greek romanian slovak czech european ethiopic
indian cyrillic chinese case-table epa-hook jka-cmpr-hook help simple
abbrev loaddefs button minibuffer faces cus-face files text-properties
overlay md5 base64 format env code-pages mule custom widget
hashtable-print-readable backquote make-network-process multi-tty emacs)

[-- Attachment #2: Type: text/html, Size: 11169 bytes --]

bug#7808: 23.2; nntp authinfo bug with async gnus

[Lars Magne Ingebrigtsen]

Robert Brown <robert.brown@gmail.com> writes:

> The code in nntp.el is getting NNTP responses that request
> authorization when requesting article 714514 on the second NNTP
> connection (nntpd<1>), but it's incorrectly providing authinfo on the
> first NNTP connection (nntpd).

I've been looking at the code and trying to follow the logic, but it
seems to boil down to the async function binding `nntp-server-buffer' to
a different buffer than the global value.  I wonder whether it's
possible that when you're queried from a sentinel that somehow that
variable binding reverts to the global value?  It seems somewhat absurd,
but I just can't understand how this could happen otherwise...

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@gnus.org * Lars Magne Ingebrigtsen

bug#7808: 23.2; nntp authinfo bug with async gnus

[Lars Ingebrigtsen]

I've been trying to reproduce this bug in Emacs 24, but I'm not able
to -- the password is always sent to the right process.  

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@gnus.org * Lars Magne Ingebrigtsen