[Python-bugs-list] [ python-Bugs-557704 ] netrc module can't handle all passwords
SourceForge.net
noreply@sourceforge.net
Wed, 23 Apr 2003 14:14:18 -0700
Bugs item #557704, was opened at 2002-05-18 12:18
Message generated for change (Comment added) made by montanaro
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=557704&group_id=5470
Category: Python Library
Group: Python 2.2.1
Status: Open
Resolution: Fixed
Priority: 7
Submitted By: Bram Moolenaar (vimboss)
Assigned to: Raymond Hettinger (rhettinger)
Summary: netrc module can't handle all passwords
Initial Comment:
When a ~/.netrc file has a password with non-word
characters parsing fails. Since it is recommended to
use punctuation characters in passwords, this means
most netrc files can't be parsed. An example of a line
in ~/.netrc that fails:
machine piet.puk.com login foo password bar!
Additionally, entries in netrc may not have a login
name (e.g., for mail servers). These entries should be
silently skipped. An example of a line that fails:
machine mail password fruit
The included diff is a partial solution. It allows all
ASCII punctuation characters to be used in passwords.
Non-ASCII characters should probably also be allowed.
----------------------------------------------------------------------
>Comment By: Skip Montanaro (montanaro)
Date: 2003-04-23 16:14
Message:
Logged In: YES
user_id=44345
Passwords with spaces are valid, however I confirmed that the ftp program
which comes with Redhat Linux also gripes about passwords containing
spaces, so my complaint is probably moot.
----------------------------------------------------------------------
Comment By: Bram Moolenaar (vimboss)
Date: 2003-04-23 16:02
Message:
Logged In: YES
user_id=57665
I am glad the special characters in passwords are now
accepted. But that is only half a fix! My ~/.netrc
contains entries without a "login" field, thus I still
cannot use the netrc module, it bails out at the first line.
Therefore I have re-opened this issue.
All other programs work just fine with this .netrc file.
Please at least do not produce the NetrcParseError when the
"login" field is omitted. This can be done by changing the
"else:" above "malformed %s entry" to "elif not password:".
That is the minimal change to make this module work on my
system.
Note to montanaro: I have not seen a .netrc file that has a
space in the password.
----------------------------------------------------------------------
Comment By: Skip Montanaro (montanaro)
Date: 2003-04-23 14:52
Message:
Logged In: YES
user_id=44345
This is still not correct, as passwords in .netrc files can't contain spaces.
The netrc module is perhaps a good demonstration of the shlex module,
but I wouldn't rely on it for actual use.
----------------------------------------------------------------------
Comment By: Raymond Hettinger (rhettinger)
Date: 2003-04-23 14:38
Message:
Logged In: YES
user_id=80475
Backported for 2.2.3.
Closing bug.
----------------------------------------------------------------------
Comment By: Guido van Rossum (gvanrossum)
Date: 2003-04-23 14:12
Message:
Logged In: YES
user_id=6380
Given the size and nature of the patch I have no problem
with a 2.2.3 backport.
----------------------------------------------------------------------
Comment By: Raymond Hettinger (rhettinger)
Date: 2003-04-23 14:00
Message:
Logged In: YES
user_id=80475
Revised netrc.py to include the additional ascii punctuation
characters. Omitted the other logic changes. See
Lib/netrc.py 1.17.
Since this is more of a feature request than a bug,
including in Py2.3 but not recommending for backporting.
----------------------------------------------------------------------
Comment By: Guido van Rossum (gvanrossum)
Date: 2003-04-22 07:28
Message:
Logged In: YES
user_id=6380
Raymond, can you deal with this or find someone else? (Maybe
the fellow who last patched shlex.py?)
----------------------------------------------------------------------
Comment By: Bram Moolenaar (vimboss)
Date: 2003-04-22 06:05
Message:
Logged In: YES
user_id=57665
Can someone please do something about this bug? It has been
open for almost a year now and it still can't handle my
netrc file. At least include a temporary fix! My patch
plus the remarks from rhettinger should be sufficient.
----------------------------------------------------------------------
Comment By: Bram Moolenaar (vimboss)
Date: 2002-11-08 05:46
Message:
Logged In: YES
user_id=57665
Note that the old Netrc class in the ftplib module has a
different approach at parsing the .netrc file. This might
actually work much better.
----------------------------------------------------------------------
Comment By: Guido van Rossum (gvanrossum)
Date: 2002-06-05 13:43
Message:
Logged In: YES
user_id=6380
I think Fred knows this code.
I think Eric Raymond (the original author) wrote this as an
example of his shlex. :-)
----------------------------------------------------------------------
Comment By: Skip Montanaro (montanaro)
Date: 2002-06-02 07:48
Message:
Logged In: YES
user_id=44345
I think a better solution would be to not use shlex to parse netrc files.
Netrc files aren't shells. The whitespace is significant if it occurs inside a
password. I'd just use re.split(r'(\s+)') and restore the password when I
encounterd the "password" keyword.
----------------------------------------------------------------------
Comment By: Raymond Hettinger (rhettinger)
Date: 2002-05-18 20:56
Message:
Logged In: YES
user_id=80475
Expanding keyspace is generally a good idea; however, the
significance of meta-characters is bound to bite someone in
the behind with a hard to find error. So, please
reconsider single-quote, double-quote, backslash,
greaterthan, lessthan, and pipe.
Looking at first part of the patch, consider:
- removing the TODO on line 31
- wrapping the character list in triple-quotes on line 32
- using the r'' form on line 32 to eliminate backslashes in
the character list
Looking at the second part of the patch, I don't follow (am
perhaps being daft) why expanding the keyspace necessitates
changing the login logic.
The idea of allowing non-ASCII characters would be cool if
the world had already universally accepted Latin-1 coding.
That conflict is the reason that site.py defaults to ASCII
encoding instead of handling non-US codings out of the box.
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=557704&group_id=5470