[tin-users] HELP! Auth bug in tin 2.4 ?

Alec Muffett alec.muffett at gmail.com
Wed Sep 21 18:45:03 CEST 2016


>
> no, but if you run tin in debug mode ("-D 1") the reason for trying to auth
> should show up in the log.
>

Hi Urs!

This appears substantially similar to what I sent previously.

The message "nntp_open() authenticate()" corresponds with auth.c line 1432

...and if I read it right it has decided to authenticate on the basis of:

 if (force_auth_on_conn_open ||
 (nntp_caps.type == CAPABILITIES &&
   !nntp_caps.reader &&
   (nntp_caps.authinfo_user || (nntp_caps.authinfo_sasl & SASL_PLAIN))))

Adding some extra debug statements shows that this expression evaluates to
True because all of:

* nntp_caps.type == CAPABILITIES
* !nntp_caps.reader
* nntp_caps.authinfo_user

...are true (and the other expressions are false) but I don't follow why
this tuple of booleans should require Tin to authenticate?

There is a comment in the code:

         * If the user wants us to authenticate on connection startup, do
it now.
         * Some news servers return "201 no posting" first, but after
successful
         * authentication you get a "200 posting allowed". To find out if
we are
         * allowed to post after authentication issue a "MODE READER" again
and
         * interpret the response code.

...but again this seems not relevant to the situation?

I am wondering whether this is a bug/not commonly encountered case, because
I am connecting to INN from an IP which also _feeds_ the server, so article
Feeding requires Auth but article Reading/Posting does not?

That might line up because, Gnus, etc, all do MODE READER and _then_ check
whether they need to authenticate - which, in this case, they do not.

    -a



nntp_open() BEGIN
nntp_open() usenet:119
<<< [16:22:36.471330] 200 usenet InterNetNews server INN 2.6.0 ready
(transit mode)
nntp_open() usenet InterNetNews server INN 2.6.0 ready (transit mode)
new_nntp_command(CAPABILITIES)
>>> [16:22:36.472123] CAPABILITIES
<<< [16:22:36.664325] 101 Capability list:
new_nntp_command(CAPABILITIES) OK
<<< [16:22:36.690737] VERSION 2
<<< [16:22:36.690945] IMPLEMENTATION INN 2.6.0
<<< [16:22:36.691058] AUTHINFO USER
<<< [16:22:36.691162] MODE-READER
nntp_open() authenticate()
nntp_open() MODE READER
>>> [16:22:36.691528] MODE READER
<<< [16:22:37.959359] 200 usenet InterNetNews NNRP server INN 2.6.0 ready
(posting ok)
new_nntp_command(CAPABILITIES)
>>> [16:22:37.960847] CAPABILITIES
<<< [16:22:38.092218] 101 Capability list:
new_nntp_command(CAPABILITIES) OK
<<< [16:22:38.119069] VERSION 2
<<< [16:22:38.119294] IMPLEMENTATION INN 2.6.0
<<< [16:22:38.145393] AUTHINFO SASL
<<< [16:22:38.145623] HDR
<<< [16:22:38.145822] LIST ACTIVE ACTIVE.TIMES COUNTS DISTRIB.PATS
DISTRIBUTIONS HEADERS MODERATORS MOTD NEWSGROUPS OVERVIEW.FMT SUBSCRIPTIONS
<<< [16:22:38.145961] OVER
<<< [16:22:38.146076] POST
<<< [16:22:38.146204] READER
<<< [16:22:38.146329] SASL DIGEST-MD5 NTLM CRAM-MD5
<<< [16:22:38.146462] STARTTLS
authorization failed
nntp_close() END
nntp_command(QUIT)
>>> [16:22:41.994303] QUIT
<<< [16:22:42.128402] 205 Bye!
nntp_command(QUIT) OK





-- 
http://dropsafe.crypticide.com/aboutalecm
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.tin.org/pipermail/tin-users/attachments/20160921/aadf6a9e/attachment.html>


More information about the tin-users mailing list