AUTHINFO

AUTHINFO

[Lars Magne Ingebrigtsen]

I've now finally fiddled with automatic authinfo thingies, so that it
should be unnecessary to put the authinfo function in the startup
hook.  Let me know in what ways the new sceme doesn't work.  :-)

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

Re: AUTHINFO

[Jason R Mastaler]

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

Lars Magne Ingebrigtsen <larsi@gnus.org> writes:

> I've now finally fiddled with automatic authinfo thingies, so that it
> should be unnecessary to put the authinfo function in the startup
> hook.  Let me know in what ways the new sceme doesn't work.  :-)

Hey great, function `nntp-send-nosy-authinfo' worked for me without help
for the first time.  How bout adding a `nntp-send-nosy-authinfo-from-file' 
to the list of available functions for those of us whose current login
name differs from the NNTP server username we authenticate with?  I'm
using the following at the moment.  My ~/.nntp-authinfo file has the
username on the first line and the password on the second line.


[-- Attachment #2: Type: text/plain, Size: 830 bytes --]

(add-hook 'nntp-server-opened-hook
          (lambda ()
            (cond ((string-match "relay" nntp-address)
                   (nntp-send-nosy-authinfo-from-file))
                  (t
                    ))))
 
(defun nntp-send-nosy-authinfo-from-file ()
  "Send the AUTHINFO to the nntp server, including username and password
  This function is supposed to be called from `nntp-server-opened-hook'."
  (when (file-exists-p "~/.nntp-authinfo")
    (nnheader-temp-write nil
      (insert-file-contents "~/.nntp-authinfo")
      (goto-char (point-min))
      (nntp-send-command
       "^.*\r?\n" "AUTHINFO USER"
       (buffer-substring (point) (progn (end-of-line) (point))))
      (goto-line 2)
      (nntp-send-command 
       "^.*\r?\n" "AUTHINFO PASS" 
       (buffer-substring (point) (progn (end-of-line) (point)))))))

Re: AUTHINFO

[Lars Magne Ingebrigtsen]

Jason R Mastaler <jason@4b.org> writes:

> Hey great, function `nntp-send-nosy-authinfo' worked for me without help
> for the first time.  How bout adding a `nntp-send-nosy-authinfo-from-file' 
> to the list of available functions for those of us whose current login
> name differs from the NNTP server username we authenticate with?  I'm
> using the following at the moment.  My ~/.nntp-authinfo file has the
> username on the first line and the password on the second line.

I think there already are too many authinfo functions, so it's time to
do something radical:  Introduce something that looks like .netrc.  It
could be called .authinforc, and it could use syntax like:

machine news.uio.no login larsi password geheimnis 

If the password (and/or user name) is missing, it will be prompted
for.  I think the default authinfo function should do this, and if the
file doesn't exist, it should prompt for both user name and password.

I think I'll just copy the ange-ftp parsing functions (somewhat); they
can't be used directly, since the set bunches of ange-ftp variables.
I'll make a generalized version instead.

Any thoughts?

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

Re: AUTHINFO

[Lars Magne Ingebrigtsen]

Lars Magne Ingebrigtsen <larsi@gnus.org> writes:

> I think there already are too many authinfo functions, so it's time to
> do something radical:  Introduce something that looks like .netrc.  It
> could be called .authinforc, and it could use syntax like:

On the other hand, why not just stick it in .netrc?

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

Re: AUTHINFO

[Jason R Mastaler]

Lars Magne Ingebrigtsen <larsi@gnus.org> writes:

> > I think there already are too many authinfo functions, so it's time to
> > do something radical:  Introduce something that looks like .netrc.  It
> > could be called .authinforc, and it could use syntax like:
> 
> On the other hand, why not just stick it in .netrc?

What goes in .netrc normally?  (I don't have such a file)

Re: AUTHINFO

[Hrvoje Niksic]

Jason R Mastaler <jason@4b.org> writes:

> Lars Magne Ingebrigtsen <larsi@gnus.org> writes:
> 
> > > I think there already are too many authinfo functions, so it's time to
> > > do something radical:  Introduce something that looks like .netrc.  It
> > > could be called .authinforc, and it could use syntax like:
> > 
> > On the other hand, why not just stick it in .netrc?
> 
> What goes in .netrc normally?  (I don't have such a file)

FTP authorization data.

netrc(4)                  File Formats                   netrc(4)

NAME
     netrc - file for ftp remote login data

DESCRIPTION
     The .netrc file contains data for logging  in  to  a  remote
     host  over  the  network for file transfers by ftp(1).  This
     file resides in the user's home  directory  on  the  machine
     initiating the file transfer.  Its permissions should be set
     to disallow read access by group and others (see chmod(1)).

     The following tokens are recognized; they may  be  separated
     by SPACE, TAB, or NEWLINE characters:

     machine name
          Identify a remote machine name.  The auto-login process
          searches  the  .netrc  file  for  a  machine token that
          matches the remote machine specified on the ftp command
          line  or  as an open command argument.  Once a match is
          made, the subsequent .netrc tokens are processed, stop-
          ping  when  the EOF is reached or another machine token
          is encountered.

     login name
          Identify a user on the remote machine.  If  this  token
          is  present,  the  auto-login  process  will initiate a
          login using the specified name.

     password string
          Supply a password.   If  this  token  is  present,  the
          auto-login  process will supply the specified string if
          the remote server requires a password as  part  of  the
          login  process.   Note: if this token is present in the
          .netrc file, ftp will abort the auto-login  process  if
          the .netrc is readable by anyone besides the user.

     account string
          Supply an additional account password.  If  this  token
          is  present,  the  auto-login  process  will supply the
          specified string if the remote server requires an addi-
          tional account password, or the auto-login process will
          initiate an ACCT command if it does not.

     macdef name
          Define a macro.  This token functions the same  as  ftp
          macdef.   A  macro  is defined with the specified name;
          its contents begin with the next .netrc line  and  con-
          tinue  until  a  null line (consecutive NEWLINE charac-
          ters)  is  encountered.   If  a  macro  named  init  is
          defined,  it is automatically executed as the last step
          in the auto-login process.

EXAMPLES
     A .netrc file containing the following line:

          machine ray login demo password mypassword

     allows an autologin to the machine ray using the login  name
     demo with password mypassword.

FILES
     ~/.netrc

SEE ALSO
     chmod(1), ftp(1), in.ftpd(1M)

SunOS 5.5.1          Last change: 3 Jul 1990                    2

-- 
Hrvoje Niksic <hniksic@srce.hr> | Student at FER Zagreb, Croatia
--------------------------------+--------------------------------
Speak softly and carry a +6 two-handed sword.

Re: AUTHINFO

[Jason R Mastaler]

Hrvoje Niksic <hniksic@srce.hr> writes:

> > > On the other hand, why not just stick it in .netrc?
> > 
> > What goes in .netrc normally?  (I don't have such a file)
> 
> FTP authorization data.

Since .netrc is already used for FTP, I think Gnus should definately
not use .netrc to hold it's NNTP authorization data, but rather it's
own file.  (for security reasons)

Re: AUTHINFO

[Lars Magne Ingebrigtsen]

Jason R Mastaler <jason@4b.org> writes:

> Since .netrc is already used for FTP, I think Gnus should definately
> not use .netrc to hold it's NNTP authorization data, but rather it's
> own file.  (for security reasons)

Well, uhm...  Why?  It isn't likely that one has the news server in
there already, and putting it there doesn't make much difference, does
it?

But I can make it a variable, of course.  `nntp-netrc-file'.

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

Re: AUTHINFO

[Jason R Mastaler]

Lars Magne Ingebrigtsen <larsi@gnus.org> writes:

> Well, uhm...  Why?  It isn't likely that one has the news server in
> there already, and putting it there doesn't make much difference, does
> it?

Well, why not?  It isn't likely, but not out of the question either.
Really, I don't see the reasoning behind using the same file for both
ftp remote login data and NNTP authentication data, especially when
both will be using the same syntax.  I don't see any pros, but I do
see points of potential conflict (even if relatively minor).  For
example, people with FTP access to their newsserver who use this Gnus
option will inadvertently be losing the FTP session password
protection they once had.  

> But I can make it a variable, of course.  `nntp-netrc-file'.

I still think the default should be a file other than .netrc, and if
one specifically wants to use .netrc, they can specify that with
`nntp-netrc-file'.

Re: AUTHINFO

[Felix Lee]

pros:
a. I only have to be careful about protecting one file, not two.
b. nntp password same as ftp password
c. less disk space wastage

cons:
a. netrc syntax is arbitrarily complex, depending on version of ftp.
--

Re: AUTHINFO

[Lars Magne Ingebrigtsen]

Jason R Mastaler <jason@4b.org> writes:

> Well, why not?  It isn't likely, but not out of the question either.
> Really, I don't see the reasoning behind using the same file for both
> ftp remote login data and NNTP authentication data, especially when
> both will be using the same syntax.  I don't see any pros, but I do
> see points of potential conflict (even if relatively minor).

Well, the pros is that the user will only have to worry about one file
containing sensitive information, and not two.

> For example, people with FTP access to their newsserver who use this
> Gnus option will inadvertently be losing the FTP session password
> protection they once had.

You mean, since the password is stored in clear text?  But that's the
case in any case.  Or do you mean that miscreants will be able to
sneak up to a logged-in terminal and ftp to the nntp server?  I hadn't
thought of that...

I dunno.  Let's have a vote:  ~/.netrc or, uhm, ~/.authinforc as the
default file?

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

Re: AUTHINFO

[Simon Josefsson]

Lars Magne Ingebrigtsen <larsi@gnus.org> writes:

> I dunno.  Let's have a vote:  ~/.netrc or, uhm, ~/.authinforc as the
> default file?

Why can't it be a emacs variable?  It seems more natural to me.

If you don't want to 'chmod 600 .emacs', you could have a '(load
"~/private/.emacs")' in your .emacs.

I'm against clogging your home directory...

Re: AUTHINFO

[Lars Magne Ingebrigtsen]

Simon Josefsson <jas@pdc.kth.se> writes:

> > I dunno.  Let's have a vote:  ~/.netrc or, uhm, ~/.authinforc as the
> > default file?
> 
> Why can't it be a emacs variable?  It seems more natural to me.

It is a variable (`nntp-netrc-file'), but the question is what it
should default to.

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

Re: AUTHINFO

[Simon Josefsson]

Lars Magne Ingebrigtsen <larsi@gnus.org> writes:

> > > I dunno.  Let's have a vote:  ~/.netrc or, uhm, ~/.authinforc as the
> > > default file?
> > 
> > Why can't it be a emacs variable?  It seems more natural to me.
> 
> It is a variable (`nntp-netrc-file'), but the question is what it
> should default to.

Sorry I wasn't clear -- I meant why can't the contents of that file be
a Emacs variable?  As I understood it, it was meant to store passwords
for NNTP, I don't really see the need for yet another dot-file.

Re: AUTHINFO

[Lars Magne Ingebrigtsen]

Simon Josefsson <jas@pdc.kth.se> writes:

> Sorry I wasn't clear -- I meant why can't the contents of that file be
> a Emacs variable?  As I understood it, it was meant to store passwords
> for NNTP, I don't really see the need for yet another dot-file.

People like editing flat text files better than editing elisp
expressions.  Since the format of the .netrc files is presumably known
to many people, storing this info in a file that uses exactly the same
syntax makes sense.

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

Re: AUTHINFO

[Per Abrahamsen]

Lars Magne Ingebrigtsen <larsi@gnus.org> writes:

> People like editing flat text files better than editing elisp
> expressions.  Since the format of the .netrc files is presumably known
> to many people, storing this info in a file that uses exactly the same
> syntax makes sense.

If the value is in a Lisp variable, they can change it with customize,
and get online help.  That should be easier for most people than
learning the ".netrc" format from a man page (I for one don't know the
".netrc" format).

Re: AUTHINFO

[Lars Magne Ingebrigtsen]

Per Abrahamsen <abraham@dina.kvl.dk> writes:

> If the value is in a Lisp variable, they can change it with customize,
> and get online help.  That should be easier for most people than
> learning the ".netrc" format from a man page (I for one don't know the
> ".netrc" format).

Uhm...  Ok.  If `nntp-authinforc-file' is an alist, it can be used.
The format should be

 '(("machine.name" (token . value) (token . value) ...)
   ...)

TOKEN can be "login" and "password".

I'm not sure how to express this in customeze.

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@ifi.uio.no * Lars Ingebrigtsen

Re: AUTHINFO

[Per Abrahamsen]

Lars Magne Ingebrigtsen <larsi@ifi.uio.no> writes:

> Per Abrahamsen <abraham@dina.kvl.dk> writes:
> 
> > If the value is in a Lisp variable, they can change it with customize,
> > and get online help.  That should be easier for most people than
> > learning the ".netrc" format from a man page (I for one don't know the
> > ".netrc" format).
> 
> Uhm...  Ok.  If `nntp-authinforc-file' is an alist, it can be used.
> The format should be
> 
>  '(("machine.name" (token . value) (token . value) ...)
>    ...)
> 
> TOKEN can be "login" and "password".
> 
> I'm not sure how to express this in customeze.

Can the tokens really appear multiple times?  Does the order matter?
If not, this might work:

(defcustom nntp-authinforc-file "~/.authinforc"
  "Docstring."
  :type '(choice file
		 (repeat :tag "Entries"
			 :menu-tag "Inline"
			 (list :format "%v"
			       :value ("" ("login" . "") ("password" . ""))
			       (string :tag "Host")
			       (checklist :inline t
					  (cons :format "%v"
						(const :format "" "login")
						(string :format "Login: %v"))
					  (cons :format "%v"
						(const :format "" "password")
						(string :format "Password: %v")))))))

BTW: "rc" stands for "run commands" and means "commands to run when
the interpreter is started".  Is that really appropriate for the
authinforc file?

Re: AUTHINFO

[Lars Magne Ingebrigtsen]

Per Abrahamsen <abraham@dina.kvl.dk> writes:

> Can the tokens really appear multiple times?  Does the order matter?

Nope (or yup); nope.

> If not, this might work:

Thanks; I've installed this in 0.28.

> BTW: "rc" stands for "run commands" and means "commands to run when
> the interpreter is started".  Is that really appropriate for the
> authinforc file?

Perhaps not, but .netrc is called .netrc even if the commands aren't
really "run" there either.  Dunno.  I can rename all the authinforc
things to authinfo (or something else).  Whaddayousay, people?

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

Re: AUTHINFO

[Joev Dubach]

Lars Magne Ingebrigtsen <larsi@gnus.org> writes:
> Per Abrahamsen <abraham@dina.kvl.dk> writes:
>> BTW: "rc" stands for "run commands" and means "commands to run when
>> the interpreter is started".  Is that really appropriate for the
>> authinforc file?

> Perhaps not, but .netrc is called .netrc even if the commands aren't
> really "run" there either.  Dunno.  I can rename all the authinforc
> things to authinfo (or something else).  Whaddayousay, people?

.newsrc also contains data, and not commands.  The historical
derivation of "rc" isn't particularly relevant when its current
meaning is "configuration information for various software".

In other words, go ahead and name it .authinforc.  Another reason is
that it's more likely that people already have a file called
".authinfo" with a different syntax, which we'd rather not force them
to clobber.  (Or work around with another variable setting.)

Joev

  "I can still remember the first time I went to my (then) inlaws for
   the holiday family gathering.  The custom was for the wimmin to
   gather in the kitchen and swap gossip while drinking tea or coffee or
   soda, while the min lounged about in front of the TV in the living
   room, drinking beer, scratching themselves, and speaking concisely
   using monosyllabic grunts.  I wound up pulling out a paperback novel,
   at which point the conversation went something like this.
   'Not a football fan, Dave?'  'Nope.'
   'Do you understand how the game is played?'
   'Ayuh.  Nail that sonuvvabitch carrying the ball.'
   'He knows it, all right.'"
          -- Dave Locke

Re: AUTHINFO

[Lloyd Zusman]

dubach@dcepea.harvard.edu (Joev Dubach) writes:

> Lars Magne Ingebrigtsen <larsi@gnus.org> writes:
> 
> [ ... ]
>
> > Perhaps not, but .netrc is called .netrc even if the commands aren't
> > really "run" there either.  Dunno.  I can rename all the authinforc
> > things to authinfo (or something else).  Whaddayousay, people?
> 
> .newsrc also contains data, and not commands.  The historical
> derivation of "rc" isn't particularly relevant when its current
> meaning is "configuration information for various software".
> 
> In other words, go ahead and name it .authinforc.  Another reason is
> that it's more likely that people already have a file called
> ".authinfo" with a different syntax, which we'd rather not force them
> to clobber.  (Or work around with another variable setting.)

What about just .authrc?  The 'info' and the 'rc' parts together
somehow seem sort of redundant to me.  Or what about .nntpauthrc ... ?

-- 
 Lloyd Zusman
 ljz@asfast.com

Re: AUTHINFO

[Lars Magne Ingebrigtsen]

Lloyd Zusman <ljz@asfast.com> writes:

> What about just .authrc?  The 'info' and the 'rc' parts together
> somehow seem sort of redundant to me.  Or what about .nntpauthrc ... ?

Per suggested putting it in "~/News/" and calling it authinfo --
without any dots.  Sounds OK to me...

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

Re: AUTHINFO

[Edward J. Sabol]

Excerpts from mail: (16-Feb-98) Re: AUTHINFO by Lars Magne Ingebrigtsen
>> BTW: "rc" stands for "run commands" and means "commands to run when
>> the interpreter is started".  Is that really appropriate for the
>> authinforc file?
>
> Perhaps not, but .netrc is called .netrc even if the commands aren't
> really "run" there either.

That's not really true. You can define macros, including a macro that runs
commands everytime you login to a specific FTP site.

However, the point about .newsrc not having any commands is certainly a valid
counterexample of a configuration file that doesn't "run commands".

> Dunno. I can rename all the authinforc things to authinfo (or something
> else). Whaddayousay, people?

I like ~/.authinfo personally, but I can live with ~/.authinforc.

Later,
Ed

Re: AUTHINFO

[Hrvoje Niksic]

Lars Magne Ingebrigtsen <larsi@gnus.org> writes:

> > For example, people with FTP access to their newsserver who use this
> > Gnus option will inadvertently be losing the FTP session password
> > protection they once had.
> 
> You mean, since the password is stored in clear text?  But that's
> the case in any case.  Or do you mean that miscreants will be able
> to sneak up to a logged-in terminal and ftp to the nntp server?  I
> hadn't thought of that...
> 
> I dunno.  Let's have a vote:  ~/.netrc or, uhm, ~/.authinforc as the
> default file?

I'd like it cleared up: Can one expect to login to FTP and NNTP
servers with different passwords?  If yes, I vote for `.authinforc'.
If not, I vote for `.netrc'.


Simon Josefsson <jas@pdc.kth.se> writes:

> Lars Magne Ingebrigtsen <larsi@gnus.org> writes:
> 
> > I dunno.  Let's have a vote:  ~/.netrc or, uhm, ~/.authinforc as the
> > default file?
> 
> Why can't it be a emacs variable?

It will be an Emacs variable -- the vote is for its default value.  :-)

-- 
Hrvoje Niksic <hniksic@srce.hr> | Student at FER Zagreb, Croatia
--------------------------------+--------------------------------
You'll notice that perl is not itself written in Perl.
                                                 -- The Perl FAQ

Re: AUTHINFO

[Lloyd Zusman]

Hrvoje Niksic <hniksic@srce.hr> writes:

> Lars Magne Ingebrigtsen <larsi@gnus.org> writes:
> 
> > > For example, people with FTP access to their newsserver who use this
> > > Gnus option will inadvertently be losing the FTP session password
> > > protection they once had.
> > 
> > You mean, since the password is stored in clear text?  But that's
> > the case in any case.  Or do you mean that miscreants will be able
> > to sneak up to a logged-in terminal and ftp to the nntp server?  I
> > hadn't thought of that...
> > 
> > I dunno.  Let's have a vote:  ~/.netrc or, uhm, ~/.authinforc as the
> > default file?
> 
> I'd like it cleared up: Can one expect to login to FTP and NNTP
> servers with different passwords?  If yes, I vote for `.authinforc'.
> If not, I vote for `.netrc'.

One can indeed expect to log in to FTP and NNTP servers with different
passwords.  On Unix boxes, the FTP password is usually the login
password for the account one is FTP-ing to.  NNTP passwords are
managed in the news server, and in my experience, they generally have
nothing to do with any login passwords in /etc/passwd.  If these
two passwords are the same, it often is a coincidence.

-- 
 Lloyd Zusman
 ljz@asfast.com

Re: AUTHINFO

[Hrvoje Niksic]

Lloyd Zusman <ljz@asfast.com> writes:

> One can indeed expect to log in to FTP and NNTP servers with
> different passwords.  On Unix boxes, the FTP password is usually the
> login password for the account one is FTP-ing to.  NNTP passwords
> are managed in the news server, and in my experience, they generally
> have nothing to do with any login passwords in /etc/passwd.  If
> these two passwords are the same, it often is a coincidence.

Thank you.

As this is the case, I think it would be seriously wrong to use
`.netrc' here.  A good name might be, say, `.authinfo' (it somehow
sounds better without `rc').

-- 
Hrvoje Niksic <hniksic@srce.hr> | Student at FER Zagreb, Croatia
--------------------------------+--------------------------------
Which is worse: ignorance or apathy?  Who knows?  Who cares?

Re: AUTHINFO

[Andy Eskilsson]

/ Hrvoje Niksic <hniksic@srce.hr> wrote:
| 
| Thank you.
| 
| As this is the case, I think it would be seriously wrong to use
| `.netrc' here.  A good name might be, say, `.authinfo' (it somehow
| sounds better without `rc').
| 

And lets do some lobbying for this so that for example Netscape can
use it, (ARGH I hate all those friggin login and passwords, or am I
the only one surfing for dirty pages :-) (Hey are there other
functions for password protected pages??)

	/Andy

Re: AUTHINFO

[Lars Magne Ingebrigtsen]

Lloyd Zusman <ljz@asfast.com> writes:

> If these two passwords are the same, it often is a coincidence.

Okidoke.  I'll have the variable default to "~/.authinforc".

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

Re: AUTHINFO

[Jason R Mastaler]

Hrvoje Niksic <hniksic@srce.hr> writes:

> I'd like it cleared up: Can one expect to login to FTP and NNTP
> servers with different passwords?  If yes, I vote for `.authinforc'.
> If not, I vote for `.netrc'.

It can be either way.  As Lloyd pointed out, the password can be
different, but it can also be the same (as in my situation).  Many
ISP's give the user one password for both FTP and NNTP.  In both
cases, problems can surface when using .netrc for both FTP and NNTP.
If you use seperate files, these potential risks/problems go away.  An
additional 1KB dot file isn't going to burn anyones disk quota, and
mentioning the file permissions issue in the manual is enough to
handle the protection issue.

Re: AUTHINFO

[Steinar Bang]

>>>>> Hrvoje Niksic <hniksic@srce.hr>:

>> I dunno.  Let's have a vote:  ~/.netrc or, uhm, ~/.authinforc as the
>> default file?

> I'd like it cleared up: Can one expect to login to FTP and NNTP
> servers with different passwords? 

Yes.

> If yes, I vote for `.authinforc'.
> If not, I vote for `.netrc'.

Re: AUTHINFO

[Jason R Mastaler]

Lars Magne Ingebrigtsen <larsi@gnus.org> writes:

> You mean, since the password is stored in clear text?  But that's the
> case in any case.  Or do you mean that miscreants will be able to
> sneak up to a logged-in terminal and ftp to the nntp server?  I hadn't
> thought of that...

I meant the second case.

> I dunno.  Let's have a vote:  ~/.netrc or, uhm, ~/.authinforc as the
> default file?

~/.authinforc

Re: AUTHINFO

[Justin Sheehy]

Lars Magne Ingebrigtsen <larsi@gnus.org> writes:

> I dunno.  Let's have a vote:  ~/.netrc or, uhm, ~/.authinforc as the
> default file?

Definitely not ~/.netrc.  Either ~/.authinforc or ~/.authinfo would
make sense.

-- 
Justin Sheehy

In a cloud bones of steel.
  

Re: AUTHINFO

[Jason R Mastaler]

Lars Magne Ingebrigtsen <larsi@gnus.org> writes:

> I think there already are too many authinfo functions, so it's time to
> do something radical:  Introduce something that looks like .netrc.  It
> could be called .authinforc, and it could use syntax like:
> 
> machine news.uio.no login larsi password geheimnis 
> 
> If the password (and/or user name) is missing, it will be prompted
> for.  I think the default authinfo function should do this, and if the
> file doesn't exist, it should prompt for both user name and password.

My only thought is that I like the idea.  Much cleaner than current
implementation.

feedback on AUTHINFO in qgnus-0.27

[Steinar Bang]

>>>>> Lars Magne Ingebrigtsen <larsi@gnus.org>:

> I think there already are too many authinfo functions, so it's time to
> do something radical:  Introduce something that looks like .netrc.  It
> could be called .authinforc, and it could use syntax like:

> machine news.uio.no login larsi password geheimnis 

> If the password (and/or user name) is missing, it will be prompted
> for.  I think the default authinfo function should do this, and if the
> file doesn't exist, it should prompt for both user name and password.

> I think I'll just copy the ange-ftp parsing functions (somewhat); they
> can't be used directly, since the set bunches of ange-ftp variables.
> I'll make a generalized version instead.

> Any thoughts?

I've tried the current version (0.27) that uses ~/.netrc in
nntp-send-authinfo, and we need a syntax for excluding machines from
password sending.  Either we don't send authinfo to machines not found
in the ~/.netrc or ~/.authinforc (or whatever) file or we put in
machine names without any password or user name.

I prefer the first approach.

Re: feedback on AUTHINFO in qgnus-0.27

[Lars Magne Ingebrigtsen]

Steinar Bang <sb@metis.no> writes:

> I've tried the current version (0.27) that uses ~/.netrc in
> nntp-send-authinfo, and we need a syntax for excluding machines from
> password sending.  Either we don't send authinfo to machines not found
> in the ~/.netrc or ~/.authinforc (or whatever) file or we put in
> machine names without any password or user name.

The new approach is to only send authinfo when challenged.  If you
want to force sending authinfo for some servers, you should put the
authinfo function into the server-opened hook for those servers. 

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

Re: feedback on AUTHINFO in qgnus-0.27

[Steinar Bang]

>>>>> Lars Magne Ingebrigtsen <larsi@gnus.org>:

> Steinar Bang <sb@metis.no> writes:
>> I've tried the current version (0.27) that uses ~/.netrc in
>> nntp-send-authinfo, and we need a syntax for excluding machines from
>> password sending.  Either we don't send authinfo to machines not found
>> in the ~/.netrc or ~/.authinforc (or whatever) file or we put in
>> machine names without any password or user name.

> The new approach is to only send authinfo when challenged.

You mean, even if I hadn't put nntp-send-authinfo into
nntp-server-opened-hook, it would have looked for authinfo in the
.netrc file, if challenged?

> If you want to force sending authinfo for some servers, you should
> put the authinfo function into the server-opened hook for those
> servers.

How do I do that? Create a function that tests the server name before
running nntp-send-authinfo, and put this function into the hook?
(seems clumsy)

Or is there a simpler way?

Re: feedback on AUTHINFO in qgnus-0.27

[Steinar Bang]

>>>>> Steinar Bang <sb@metis.no>:

>>>>> Lars Magne Ingebrigtsen <larsi@gnus.org>:

>> If you want to force sending authinfo for some servers, you should
>> put the authinfo function into the server-opened hook for those
>> servers.

> How do I do that? Create a function that tests the server name before
> running nntp-send-authinfo, and put this function into the hook?
> (seems clumsy)

> Or is there a simpler way?

Like this, maybe...?
(setq nntp-server-action-alist
      (append
       '(("news\.hyssing\.net"
	 (add-hook 'nntp-server-opened-hook 'nntp-send-authinfo)))
       nntp-server-action-alist))

Still seems clumsy, though.  And since I put the alist in .gnus.el,
it'll presumably keep growing with every restart?

Oh well! It now works, and I'll let it keep running.

Re: feedback on AUTHINFO in qgnus-0.27

[Lars Magne Ingebrigtsen]

Steinar Bang <sb@metis.no> writes:

> You mean, even if I hadn't put nntp-send-authinfo into
> nntp-server-opened-hook, it would have looked for authinfo in the
> .netrc file, if challenged?

It wouldn't have, but now it will.  :-)

> > If you want to force sending authinfo for some servers, you should
> > put the authinfo function into the server-opened hook for those
> > servers.
> 
> How do I do that?

Define `nntp-server-opened-hook' in the virtual server definition.
(I.e., from the server buffer.)

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

Re: feedback on AUTHINFO in qgnus-0.27

[Steinar Bang]

>>>>> Lars Magne Ingebrigtsen <larsi@gnus.org>:

> The new approach is to only send authinfo when challenged.  If you
> want to force sending authinfo for some servers, you should put the
> authinfo function into the server-opened hook for those servers. 

I prefer an approach where you always check ~/.autinforc (or
whatever), for the server, and send authinfo whether challenged or
not. 

The only place I use authinfo, is to gain extra access to a server
that doesn't challenge.

I'd like to minimize the configuration hazzle for this.

You don't have to reread the ~/authinfo file all the time, you just
read the contents into an alist and re-read when the file has changed
on the disk.

This alist could have the same form as the one configurable by custom
(is it possible to configure it using custom, and write the results
back to the ~/.authinforc file?)

Re: feedback on AUTHINFO in qgnus-0.27

[Steinar Bang]

>>>>> Steinar Bang <sb@metis.no>:

>>>>> Lars Magne Ingebrigtsen <larsi@gnus.org>:
>> The new approach is to only send authinfo when challenged.  If you
>> want to force sending authinfo for some servers, you should put the
>> authinfo function into the server-opened hook for those servers. 

> I prefer an approach where you always check ~/.autinforc (or
> whatever), for the server, and send authinfo whether challenged or
> not. 

Ie. the following behaviour:
 1. if authinfo entry for this server found, send it whether
    challenged or not, prompt for username and password if missing 
 2. if no authinfo entry found, and no challenge is issued don't send
    authinfo 
 3. If challenged look for authinfo for the server in the
    ~/.authinforc, and prompt for missing username and password, the
    way it presumably does

Re: feedback on AUTHINFO in qgnus-0.27

[Lars Magne Ingebrigtsen]

Steinar Bang <sb@metis.no> writes:

>  1. if authinfo entry for this server found, send it whether
>     challenged or not, prompt for username and password if missing 
>  2. if no authinfo entry found, and no challenge is issued don't send
>     authinfo 
>  3. If challenged look for authinfo for the server in the
>     ~/.authinforc, and prompt for missing username and password, the
>     way it presumably does

Why should 3) look into .authinforc when 1) already has established
that it doesn't exist there?

Anyways, the problem is to decide which servers to send authinfo to
automatically.  I say we add some token to .authinforc -- "force",
perhaps?  Or (to keep compatibility with .netrc), have the user name
be of a certain form?  "login force:larsi" to say to nntp that it
should always send authinfo for this server?  

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

Re: feedback on AUTHINFO in qgnus-0.27

[Steinar Bang]

>>>>> Lars Magne Ingebrigtsen <larsi@gnus.org>:

> Steinar Bang <sb@metis.no> writes:
>> 1. if authinfo entry for this server found, send it whether
>>    challenged or not, prompt for username and password if missing 
>> 2. if no authinfo entry found, and no challenge is issued don't send
>>    authinfo 
>> 3. If challenged look for authinfo for the server in the
>>    ~/.authinforc, and prompt for missing username and password, the
>>    way it presumably does

> Why should 3) look into .authinforc when 1) already has established
> that it doesn't exist there?

Indeed.  I got a bit ahead of myself in my eagerness to convince
you...:-)

> Anyways, the problem is to decide which servers to send authinfo to
> automatically.  I say we add some token to .authinforc -- "force",
> perhaps?  Or (to keep compatibility with .netrc), have the user name
> be of a certain form?  "login force:larsi" to say to nntp that it
> should always send authinfo for this server?  

Both will work for me.  And keeping as much compatibility with .netrc
as possible sounds like a good thing? (Unless usernames with colons in
them may exist on certain newsservers, and this may cause problems...?
Not likely, but you never know...)


- Steinar

Re: feedback on AUTHINFO in qgnus-0.27

[Edward J. Sabol]

Excerpts from mail: (17-Feb-98) Re: feedback on AUTHINFO in qgnus-0.27 by Steinar Bang
Lars Magne Ingebrigtsen <larsi@gnus.org> writes:
Lars> The new approach is to only send authinfo when challenged.  If you
Lars> want to force sending authinfo for some servers, you should put the
Lars> authinfo function into the server-opened hook for those servers. 

Steinar Bang <sb@metis.no> writes:
SB> I prefer an approach where you always check ~/.autinforc (or
SB> whatever), for the server, and send authinfo whether challenged or
SB> not. 

SB> Ie. the following behaviour:
SB> 1. if authinfo entry for this server found, send it whether
SB>    challenged or not, prompt for username and password if missing 
SB> 2. if no authinfo entry found, and no challenge is issued don't send
SB>    authinfo 
SB> 3. If challenged look for authinfo for the server in the
SB>    ~/.authinforc, and prompt for missing username and password, the
SB>    way it presumably does

Lars> Why should 3) look into .authinforc when 1) already has established
Lars> that it doesn't exist there?

Lars> Anyways, the problem is to decide which servers to send authinfo to
Lars> automatically.  I say we add some token to .authinforc -- "force",
Lars> perhaps?  Or (to keep compatibility with .netrc), have the user name
Lars> be of a certain form?  "login force:larsi" to say to nntp that it
Lars> should always send authinfo for this server?  

No, please don't do that. It's completely unnecessary and deviates from the
intentions of the .netrc file format. Sematically overloading a syntax is
almost never the correct way of doing things. If I may, let me reorder and
rewrite Steinar's procedure of how to handle this:

1. If challenged by some server, look for authinfo for that server in the
   ~/.authinforc file.
   a. If there is no ~/.authinforc file or if there is but there isn't an
      entry for the current server in it, prompt for username and password
      and then send the authentication information to the server.
   b. If there is an entry for the current server in ~/.authinforc but it
      lacks a username and password, prompt the user to enter them
      and then send the authentication information to the server.
   c. If there is an entry for the current server in ~/.authinforc and a
      username is specified but it lacks the associated password, prompt the
      user for the password and then send the authentication information to
      the server.
2. If no challenge is issued by the server, look for authinfo for that server
   in the ~/.authinforc file anyway.
   a. If there is no entry in the ~/.authinforc file for the current server
      or if no ~/.authinforc file exists, don't send any authentication
      information to the server.
   b. If there is an entry in the ~/.authinforc file for the current server
      but it lacks a username and password, prompt the user to enter them
      and then send the authentication information to the server.
   c. If there is an entry for the current server in ~/.authinforc and a
      username is specified but it lacks the associated password, prompt the
      user for the password and then send the authentication information to
      the server.

It sounds more complicated than it really is. Basically, if there's an entry
for the server in ~/.authinforc, then send authinfo for that server whether
challenged or not.

By the way, this is almost exactly how FTP uses the username and password
information in the ~/.netrc file.

Later,
Ed

Re: feedback on AUTHINFO in qgnus-0.27

[Lars Magne Ingebrigtsen]

"Edward J. Sabol" <sabol@alderaan.gsfc.nasa.gov> writes:

> It sounds more complicated than it really is. Basically, if there's an entry
> for the server in ~/.authinforc, then send authinfo for that server whether
> challenged or not.

Hm.  Some servers only challenge when entering certain groups.  The
user may wish to stick the machine name and the user name into the
file, but not the password, and it would be annoying if that would
lead Gnus to send the authinfo (and promt the user for that
unnecessary password) even if the user doesn't want to read the
password-protected groups.

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

Re: feedback on AUTHINFO in qgnus-0.27

[Steinar Bang]

>>>>> Lars Magne Ingebrigtsen <larsi@gnus.org>:

> "Edward J. Sabol" <sabol@alderaan.gsfc.nasa.gov> writes:
>> It sounds more complicated than it really is. Basically, if there's an entry
>> for the server in ~/.authinforc, then send authinfo for that server whether
>> challenged or not.

> Hm.  Some servers only challenge when entering certain groups.  

Does it matter if Gnus sends authinfo before it is challenged?

Re: feedback on AUTHINFO in qgnus-0.27

[Lars Magne Ingebrigtsen]

Steinar Bang <sb@metis.no> writes:

> Does it matter if Gnus sends authinfo before it is challenged?

It is annoying to have to type a password unless it is really
required. 

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

Re: feedback on AUTHINFO in qgnus-0.27

[Steinar Bang]

>>>>> Lars Magne Ingebrigtsen <larsi@gnus.org>:

> Steinar Bang <sb@metis.no> writes:
>> Does it matter if Gnus sends authinfo before it is challenged?

> It is annoying to have to type a password unless it is really
> required. 

True.  It also clashes with demonical fetching.  Should
prompted for username/password pairs be stored throughout a session. 

Re: feedback on AUTHINFO in qgnus-0.27

[Lars Magne Ingebrigtsen]

Steinar Bang <sb@metis.no> writes:

>  Should prompted for username/password pairs be stored throughout a
> session.

That's what happens now.  Or, at least, that's what's supposed to
happen now, but I haven't checked.

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

Re: feedback on AUTHINFO in qgnus-0.27

[Aaron M. Ucko]

Steinar Bang <sb@metis.no> writes:

> True.  It also clashes with demonical fetching.  Should
> prompted for username/password pairs be stored throughout a session. 

Perhaps Gnus could have a variable timeout like mailcrypt.

-- 
Aaron M. Ucko, KB1CJC <amu@mit.edu> (finger amu@monk.mit.edu)

Re: feedback on AUTHINFO in qgnus-0.27

[Edward J. Sabol]

Excerpts from mail: (20-Feb-98) Re: feedback on AUTHINFO in qgnus-0.27 by Lars Magne Ingebrigtsen

"Edward J. Sabol" <sabol@alderaan.gsfc.nasa.gov> writes:
Ed> It sounds more complicated than it really is. Basically, if there's an entry
Ed> for the server in ~/.authinforc, then send authinfo for that server whether
Ed>> challenged or not.

Lars Magne Ingebrigtsen <larsi@gnus.org> writes:
Lars> Hm.  Some servers only challenge when entering certain groups.  The
Lars> user may wish to stick the machine name and the user name into the
Lars> file, but not the password, and it would be annoying if that would
Lars> lead Gnus to send the authinfo (and promt the user for that
Lars> unnecessary password) even if the user doesn't want to read the
Lars> password-protected groups.

Steinar Bang <sb@metis.no> writes:
Steinar> Does it matter if Gnus sends authinfo before it is challenged?

Lars> It is annoying to have to type a password unless it is really
Lars> required. 

Hmmmmm. Good point. I haven't had a chance to upgrade to the latest Quassia
yet, so forgive the question, but does the netrc parsing code you snarfed
from ange-ftp parse the macdefs (marco definitions)? If not, maybe it could
be modified to do so. So instead of semantically overloading the username as
you suggested, we could define a macro which could be used as a flag to
determine whether to force authinfo or not. For example,

machine news.foobar.com login baz password xyzzy
macdef nntp_init
force authinfo

Later,
Ed

Re: feedback on AUTHINFO in qgnus-0.27

[Lars Magne Ingebrigtsen]

"Edward J. Sabol" <sabol@alderaan.gsfc.nasa.gov> writes:

> Hmmmmm. Good point. I haven't had a chance to upgrade to the latest Quassia
> yet, so forgive the question, but does the netrc parsing code you snarfed
> from ange-ftp parse the macdefs (marco definitions)?

Nope.

> If not, maybe it could be modified to do so.

Yup.  

> So instead of semantically overloading the username as
> you suggested, we could define a macro which could be used as a flag to
> determine whether to force authinfo or not. For example,
> 
> machine news.foobar.com login baz password xyzzy
> macdef nntp_init
> force authinfo

Well, how would the user specify that authinfo should be forced onto
server news.foobar.com and not news.barfoo.com?

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

Re: feedback on AUTHINFO in qgnus-0.27

[Edward J. Sabol]

Excerpts from mail: (21-Feb-98) Re: feedback on AUTHINFO in qgnus-0.27 by Lars Magne Ingebrigtsen
"Edward J. Sabol" <sabol@alderaan.gsfc.nasa.gov> writes:
Ed> So instead of semantically overloading the username as
Ed> you suggested, we could define a macro which could be used as a flag to
Ed> determine whether to force authinfo or not. For example,
Ed> 
Ed> machine news.foobar.com login baz password xyzzy
Ed> macdef nntp_init
Ed> force authinfo

Lars> Well, how would the user specify that authinfo should be forced onto
Lars> server news.foobar.com and not news.barfoo.com?

Since the "macdef" comes after "machine news.foobar.com", it only applies to
that host and not to any other. That's completely consistent with the way FTP
parses the ~/.netrc file and uses the "init" macro (and any others you define
for a given host). In other words, the macros are defined on a per-host
basis. To answer your question specifically, here is how you do it:

-~/.authinfo------
machine news.foobar.com login baz password xyzzy
macdef nntp_init
force authinfo

machine news.barfoo.com login zab password yzzyx
------------------

This method retains maximum compatibility with ~/.netrc to the point where
you can still use the same file for both (assuming usernames and passwords
are the same for NNTP and for login, of course). (If you implement this,
please note that multiple macros other than "nntp_init" may be defined for a
given host, but Gnus should only concern itself with the "nntp_init" macro.)

Later,
Ed

Re: feedback on AUTHINFO in qgnus-0.27

[Lars Magne Ingebrigtsen]

"Edward J. Sabol" <sabol@alderaan.gsfc.nasa.gov> writes:

> Since the "macdef" comes after "machine news.foobar.com", it only applies to
> that host and not to any other. That's completely consistent with the way FTP
> parses the ~/.netrc file and uses the "init" macro (and any others you define
> for a given host).

Ok.

> In other words, the macros are defined on a per-host
> basis. To answer your question specifically, here is how you do it:
> 
> -~/.authinfo------
> machine news.foobar.com login baz password xyzzy
> macdef nntp_init
> force authinfo
> 

This is certainly workable, and would provide compatibility with
.netrc files.  But it is rather obscure.

Is compatibility with .netrc files all that important?  How about if
we just add a "force" token?

machine news.foobar.com login baz password xyzzy force yes

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

Re: feedback on AUTHINFO in qgnus-0.27

[Edward J. Sabol]

Excerpts from mail: (21-Feb-98) Re: feedback on AUTHINFO in qgnus-0.27 by Lars Magne Ingebrigtsen
> Is compatibility with .netrc files all that important?  How about if
> we just add a "force" token?
>
> machine news.foobar.com login baz password xyzzy force yes

That works, I guess. I suppose compatibility with .netrc files isn't all that
important. It doesn't really take much more effort to maintain another file.

Have you added any permission checks to Gnus? FTP gives an error if passwords
are listed in ~/.netrc and the permissions are not 600. I think it would be
wise if Gnus would do the same thing.

Later,
Ed

Re: feedback on AUTHINFO in qgnus-0.27

[Lars Magne Ingebrigtsen]

"Edward J. Sabol" <sabol@alderaan.gsfc.nasa.gov> writes:

> Have you added any permission checks to Gnus? FTP gives an error if passwords
> are listed in ~/.netrc and the permissions are not 600. I think it would be
> wise if Gnus would do the same thing.

I dunno.  Why should programs police the behaviors of users?

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

Re: feedback on AUTHINFO in qgnus-0.27

[Edward J. Sabol]

Excerpts from mail: (27-Feb-98) Re: feedback on AUTHINFO in qgnus-0.27 by Lars Magne Ingebrigtsen
>> Have you added any permission checks to Gnus? FTP gives an error if passwords
>> are listed in ~/.netrc and the permissions are not 600. I think it would be
>> wise if Gnus would do the same thing.
>
> I dunno.  Why should programs police the behaviors of users?

I dunno. Ask the authors of ftp, ncftp, rsh/rlogin/rcp, and ssh/slogin/scp.

Re: feedback on AUTHINFO in qgnus-0.27

[Lars Magne Ingebrigtsen]

"Edward J. Sabol" <sabol@alderaan.gsfc.nasa.gov> writes:

> > I dunno.  Why should programs police the behaviors of users?
> 
> I dunno. Ask the authors of ftp, ncftp, rsh/rlogin/rcp, and ssh/slogin/scp.

I dunno.  Sounds like lots of work.  Why don't I ask you instead?

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

Re: feedback on AUTHINFO in qgnus-0.27

[Hallvard B Furuseth]

Edward J. Sabol <sabol@alderaan.gsfc.nasa.gov> writes:
 
>> I dunno.  Why should programs police the behaviors of users?
> 
> I dunno. Ask the authors of ftp, ncftp,

Probably just to help the user discover his self-made problems.
I think it makes sense that when only a few programs use a file, like an
init file, they help the user catch security problems with that file.

> rsh/rlogin/rcp, and ssh/slogin/scp.

This is to avoid a security hole.  These programs should check file
permissions, owner, and maybe that it is a plain file.  If my ~/.rhosts
is world-writeable or owned by someone else, it may be because someone
has broken in and added themselves to my ~/.rhosts file.

-- 
Hallvard

Re: feedback on AUTHINFO in qgnus-0.27

[Jason R Mastaler]

Lars Magne Ingebrigtsen <larsi@gnus.org> writes:

> > Have you added any permission checks to Gnus? FTP gives an error if passwords
> > are listed in ~/.netrc and the permissions are not 600. I think it would be
> > wise if Gnus would do the same thing.
> 
> I dunno.  Why should programs police the behaviors of users?

Because users are often careless, and their careless actions can
result in dire consequences.

It's more of a courtesy and security safegaurd than a censor.

Think of it another way.  When would anyone ever _not_ want 
permissions of 600 on a plaintext file containing passwords?

If you are opposed to Gnus refusing to use a .authinforc with
incorrect permissions, than maybe just have it print an appropriate
warning but still run, thus allowing the user to make a more informed
choice?

Re: feedback on AUTHINFO in qgnus-0.27

[Lars Magne Ingebrigtsen]

Jason R Mastaler <jason@4b.org> writes:

> Because users are often careless, and their careless actions can
> result in dire consequences.

Yes... 

> It's more of a courtesy and security safegaurd than a censor.
> 
> Think of it another way.  When would anyone ever _not_ want 
> permissions of 600 on a plaintext file containing passwords?

Well, I can't think of why anyone would leave the home directory world
writable, but I'm certainly not going to check whether the user has
done so or not.  Etc.

But that's something that rarely happens, while many users do leave
.rhosts (etc.) world readable by mistake, so it is (perhaps)
reasonable to warn them about what they have done.

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