Skip to content
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

Open
reinux opened this issue Dec 23, 2023 · 10 comments
Open

Needs support for quoted passwords #12

reinux opened this issue Dec 23, 2023 · 10 comments

Comments

@reinux
Copy link

reinux commented Dec 23, 2023

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

@reinux
Copy link
Author

reinux commented Dec 23, 2023

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.

@andreasabel
Copy link
Member

Currently whitespace is explicitly forbidden in passwords and other fields:

-- > ENTRY := 'machine' WS+ <value> WS+ ((account|username|password) WS+ <value>)*
-- > | 'default' WS+ (('account'|'username'|'password') WS+ <value>)*
-- > | 'macdef' <value> LF (<line> LF)* LF
-- >
-- > WS := (LF|SPC|TAB)
-- >
-- > <line> := !LF+
-- > <value> := !WS+

-- | @machine@ and @default@ entries describe remote accounts
--
-- __Invariant__: fields must not contain any @TAB@s, @SPACE@, or @LF@s.
data NetRcHost = NetRcHost
{ nrhName :: !ByteString -- ^ Remote machine name (@""@ for @default@-entries)
, nrhLogin :: !ByteString -- ^ @login@ property (@""@ if missing)
, nrhPassword :: !ByteString -- ^ @password@ property (@""@ if missing)

@reinux
Copy link
Author

reinux commented Dec 24, 2023

From what I understand, there's not much of an official standard. I wonder if the robustness principle might apply in this case?

@andreasabel
Copy link
Member

If you allow passwords in quotes, what happens to passwords that contained quotes?
E.g., in password "foo" the password is currently the 5-character "foo", not the 3-character foo.

@reinux
Copy link
Author

reinux commented Dec 26, 2023

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.

@reinux
Copy link
Author

reinux commented Dec 26, 2023

Actually, I just had a weird idea: What if, if the first line of the starts with a comment like #allow spaces, it allows spaces within quotes?

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.

@andreasabel
Copy link
Member

Thanks for linking the article https://daniel.haxx.se/blog/2022/05/31/netrc-pains/ !

What if, if the first line of the starts with a comment like #allow spaces, it allows spaces within quotes?

Worth considering, however, we would create our own standard here, which I am hesitant about.
In the end, we are just a dwarf, and we should follow one of the giants, and not try to take the lead.

It seems more plausible to follow the decision that curl took, to switch to (double) quoted passwords with backslash-escaped double quotes inside the password.

We are in the lucky situation that we do not seem to have too many users, according to https://packdeps.haskellers.com/reverse/netrc .
So we can ask our users for their opinion:

@shlevy
Copy link

shlevy commented Dec 31, 2023

Following curl makes sense to me.

@andreasabel
Copy link
Member

@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.

@reinux
Copy link
Author

reinux commented Jan 12, 2024

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!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants