ssh: disable repository config password

• It would prevent people from pushing their passwords to public Git hosting servers
• I don't see any use case where this is "needed" or at least "desired"

Use --local, --system or --global

@efiop, why this is not important? 🤔

This is a design flaw that can expose user's credentials

[efiop]

@MrOutis Not everyone is really comfortable with ssh keys and might just want to try it out first with a password, same as he is able to simply ssh into another box using a password. So it doesn't harm to leave it as an option, there are a lot of other ways one could shoot himself in the leg, and this one is a pretty obvious one and easy to avoid.

my bad, @efiop , I didn't want to disable the global config 🙈 , but the repository config; if you are using "password" it shouldn't end in the .dvc/config file

[efiop]

@MrOutis But you might want to have a shared password, who knows :) I mean, the care should be taken, but is this really something that we should forbid specifically for .dvc/config? Seems excessive.

[shcheklein]

It would be nice to have a warning at least? It can save a lot of time. It's one of the common mistakes people do - commit credentials to github.

[efiop]

@shcheklein That also seems like an unnecessary complication. Generally not putting passwords into your configs is a piece of common knowledge, I don't think we need to explicitly protect against that. The implementation is not trivial and the value is questionable, we haven't seen any complaints about it at all. Also, if someone is indeed doing that for a reason, then he will be not happy about warnings and will ask us to implement a config option to disable that specific warning (like guys using fish), which is yet another piece of code that we don't need with questionable usefulness.

[shcheklein]

@efiop It's not a "common knowledge". Even if people are aware about this problem they still keep doing it for a variety of reasons. There are even tools like this https://github.com/awslabs/git-secrets to prevent this from happening. There are blog posts like this: https://help.github.com/en/articles/removing-sensitive-data-from-a-repository and like this https://pomeroy.me/2017/10/stop-committing-credentials-to-github/ (with some links to how easy it is to discover secrets on public Github, and on private - don't even ask me - it's terrible :) ).

May be I'm missing something, but why is it "non-trivial"? I also don't see how a simple message (I would actually prefer aborting in this case, and when you try to save S3/GCS/etc credentials to project's config) can harm the interface.

I understand that there is a philosophy of building tools for "professionals" - brutal command line, no docs, you know what you do philosophy. Following it we should be overwriting data for example - because, users should be aware about what they doing. But, even if I share it in general, I don't see any reasons of not putting some nice safe-guards, nice help messages that can save someone a lot of time. After all trying to save password to the project's config is a mistake in 99% of the time. May be even 100%. (at least I would never allow this in my team).

Also, another consideration. Even if I'm aware about the concept of not committing sensitive stuff, it's not immediately clear that dvc remote modify leads to this. People can run git commit -a -m (not a good idea by itself, but we are humans) after that easily.

@MrOutis But you might want to have a shared password, who knows :) I mean, the care should be taken, but is this really something that we should forbid specifically for .dvc/config? Seems excessive.

Agree, @efiop , I have no problem closing this one

[efiop]

@shcheklein Sorry for not replying to each part of your comment, but I will ask another question instead to save us some time. Ok, so storing your password in .dvc/config is bad because it will be stored in git. Isn't generally storing passwords in plain text harmful? Haven't we seen a lot of fuss about that? Yeah, we've seen that. So now we need to protect users from using password in config at all, right? Warnings? Or should we simply remove it from config at all? I would remove that, but people might want to use it for multiple reasons.

[shcheklein]

@efiop I don't suggest removing it. Just make this action a bit more explicit. Implementation seems to me simple, and it can vary from a simple warning (that what we already do in our docs, btw) to only allow changing it manually, for example. You will have to just put a bit of extra effort (in case of warning even no extra effort) to put secrets into .dvc/config.

(please, let's not shift the discussion to a more general topic - plain text secrets, we can discuss it separately to keep this conversation focused)

Btw, what are the reasons to save secrets into Git? Can you name me or point me to some examples?

Btw, what are the reasons to save secrets into Git? Can you name me or point me to some examples?

@shcheklein , some people like to have credentials in the repository (encrypt & push -> pull & decrypt) https://guides.rubyonrails.org/security.html#custom-credentials