-
Notifications
You must be signed in to change notification settings - Fork 6
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Needs support for quoted passwords #12
Comments
In order to minimize the likelihood of breakage, I wonder if it might make sense to treat a column as having been quoted if the quote only appears at the beginning and end of the column... It's not exactly the correct way to parse quotes, but there probably isn't a better option. |
Currently whitespace is explicitly forbidden in passwords and other fields: Lines 14 to 21 in bee52c7
Lines 66 to 72 in bee52c7
|
From what I understand, there's not much of an official standard. I wonder if the robustness principle might apply in this case? |
If you allow passwords in quotes, what happens to passwords that contained quotes? |
From a quick glance at what other programs do, wget and curl share one escaping style, fetchmail has its own, curl pre-7.84.0 and git don't accept spaces, and perl's netrc library, lftp, and ftp accept spaces. Unfortunately something would be lost no matter what, as there's no specification as to which is correct. More broadly, modern websites and services are agnostic to spaces (of course, any website that is actually checking the content of a password server-side is very sus), and more and more are issuing passphrases as opposed to passwords, as they're easier to remember. I think the chances that a password begins and ends with a quote are fairly slim, so the risk of breaking something is probably not too severe, though I acknowledge that it could lead to unexpected downtime of a critical service. |
Actually, I just had a weird idea: What if, if the first line of the starts with a comment like That way, at least, programs that don't already specify a way of allowing spaces, e.g. git and haskell-hvr, have a chance of being consistent. |
Thanks for linking the article https://daniel.haxx.se/blog/2022/05/31/netrc-pains/ !
Worth considering, however, we would create our own standard here, which I am hesitant about. It seems more plausible to follow the decision that We are in the lucky situation that we do not seem to have too many users, according to https://packdeps.haskellers.com/reverse/netrc . |
Following |
@reinux: Do you want to PR? Probably the desired logic looks like this: if the password begins and ends with a doublequote, we drop those and unescape backslashed double quotes and backslashes inside the password; otherwise, we use the password literally. |
Aight, I'll give it a shot. I spent most of my adult life in F# and haven't touched Haskell much since college (worked a bit with FParsec though), so this'll be a good small project to get reacquainted. Looking forward to feedback when it's ready! |
Network.NetRc is not one of the many (most?) programs that accept quotes in the password column so that the passwords can have spaces in them.
Unfortunately, some services issue passphrases that contain spaces (and passphrases are becoming a more common way to generate passwords, as they are easier to remember), and it isn't up to the user to change them.
More info: https://stackoverflow.com/questions/12674888/can-netrc-handle-passphrases-with-spaces
The text was updated successfully, but these errors were encountered: