possible fix for #910

[henryas]

Possible fix for issue #910

[dom96]

Instead of this just strip the username and password using the uri module.

[henryas]

So which do you guys prefer? If the url is dirty, ask the user for a new one, or attempt to fix it as @dom96 suggested?

As for @dom96 idea, I was thinking of deleting everything between "https://" up to the first "@" (inclusive), but then I am concerned that it may not always be correct since I do not know the exhaustive list of possible combination in the url.

[henryas]

In addition, there is another possibility in which passwords and tokens may be supplied in the url, which is via http get. I don't think github allows that and it is not recommended to do that, but some other sites might. I don't think it is possible to properly scrub such information in http get urls. How do you know which argument is the password/token?

I am thinking to just detect for any '@' or '?' in the url, and ask the user if any such characters is found. What do you think?

[Araq]

I am thinking to just detect for any '@' or '?' in the url, and ask the user if any such characters is found. What do you think?

I agree with this solution.

[dom96]

In the URI RFCs the data between https:// and @ is referred to as the username and password. You can see the uri module in Nim's stdlib also refers to these in the same way: https://nim-lang.org/docs/uri.html#Uri

You don't need to do any parsing yourself, just parseUri the url, clear username and password, then call $ on it.

In addition, there is another possibility in which passwords and tokens may be supplied in the url, which is via http get. I don't think github allows that and it is not recommended to do that, but some other sites might. I don't think it is possible to properly scrub such information in http get urls. How do you know which argument is the password/token?

This isn't something that any sane website would allow, we shouldn't be detecting for this.

[dom96]

Actually, thinking about it some more. I think we should just quit if the URL contains any passwords, this is because it implies that the URL won't work without them, the user should change their git remote.

So I would say:

• Call parseUri
• Check for password
• if it's not empty: raise NimbleError("Your git remote contains a plaintext password! Publishing it to Nimble would make the password public, change your git remote to continue")

You can add a hint to the error as well to instruct the user on how to fix their git remote.

[henryas]

I have a couple of questions: what to do when the url contains password and the detection algorithm.

First, if the url contains a password or an access token, based on the feedback so far, we have several options:

1. Terminate nimble publish and tell the user to fix their remote url.

2. Proceed with nimble publish but ask the user to enter a new url.

3. Proceed with nimble publish, ask the user to enter a new url, and drop a hint that their remote url contains security risk. I am not sure if it is our responsibility to do this though. Such url is probably not designed to be read by a third party application such as nimble. Adding a quote from https://www.oauth.com/oauth2-servers/access-tokens/:

   Access tokens must be kept confidential in transit and in storage. The only parties that should ever see the access token are the application itself, the authorization server, and resource server. The application should ensure the storage of the access token is not accessible to other applications on the same device. The access token can only be used over an https connection, since passing it over a non-encrypted channel would make it trivial for third parties to intercept.

I personally prefer option no 2.

Second, regarding detection algorithm, wouldn't it be more efficient to detect the @ character than to parse the whole uri into their individual classifications before deciding whether a password exists? Is there any case where merely detecting '@' will fail?

Regarding http get, I did a little research and it turns out it is fairly common to have something like https://<base url>?access_token=<token> and Twitter allows it. What I am not clear is whether, in Twitter's case, it is a semi-permanent token (like in github) or a session token. Upon reflection, http://<username>:<password>@hostname.com/path is just as risky as https://<base url>?access_token=<token>. They both involve encoding sensitive information into the url and the assumption is that the url does not get intercepted. In our case, nimble intercepts the url from a misconfigured git.

Do we need to cover for the case of http get? I am ambivalent about this. I am fine either way whether we cover http get or not.

Let's decide on this and hopefully we can reach a consensus and get this over with.

[dom96]

I prefer (1) because like your oauth quote supports: other applications being able to access the oauth token is a security risk. Nimble should scream at the user about it, not silently ignore it and ask for a git URL.

Second, regarding detection algorithm, wouldn't it be more efficient to detect the @ character than to parse the whole uri into their individual classifications before deciding whether a password exists? Is there any case where merely detecting '@' will fail?

We're not parsing gigabytes of data here. Don't optimise prematurely. Parsing the URL will take care of edge cases that we may not predict and it's much clearer about what's being done.

They both involve encoding sensitive information into the url and the assumption is that the url does not get intercepted. In our case, nimble intercepts the url from a misconfigured git.

If your URI is accessible in plaintext inside a commonly accessed file then there is no such assumption.

But if you really want you can also make Nimble quit when the query field is non-empty. I don't think we have a single package that requires it anyway so it's unlikely to be a problem and it may just save someone from exposing some silly URL.