Use `--local` for basic remote setup?

Hi there, not sure if this is a bug or a feature, but the docs are suggesting to store .dvc/config in git.

Which seemed fine at first, but then I noticed that my Azure Blob Storage account (i.e. my Azure username) is also stored in .dvc/config, which means it would end up in git. Which is not ideal for team collaboration scenarios. What’s less ideal (read: really scary) is that connection strings entered using dvc remote modify blah connection_string ... also end up in .dvc/config, making them end up in git, making them end up in interesting places for open source projects.

Am I doing something obviously wrong? I wouldn’t expect the getting started docs to go very deep into security issues, but I wouldn’t expect them to store connection strings in source control either.

[vladiliescu]

Let me illustrate my case:

git init
# git repo created

dvc init
# dvc initialized, https://dvc.org/doc/start

dvc add data/data.xml
# data.xml is added to dvc

git add .
# initial dvc meta is added to git

git commit -m "First commit"
# committed

# At this point assuming you don't want to use S3 but Azure, you go to https://dvc.org/doc/command-reference/remote/add , visit supported Storage Types, and find the following commands in there:

dvc remote add -d myremote azure://mycontainer/path
# ./dvc/config is updated to include a reference to myremote

dvc remote modify myremote account_name 'myuser'
# my Azure email account is stored in .dvc/config, and in git

Assuming you don’t see the --local flag when quickly scanning the command reference (and not the command examples, which don’t include it), the first command example you’d encounter is if you felt the need to scroll really down in the Available parameteres per storage section. Which you may or may not do.

@vladiliescu so if you follow https://dvc.org/doc/start/data-and-model-versioning#storing-and-sharing specifically, no secrets get to .dvc/config, only the URL to your remote. Then there’s a note with a link to https://dvc.org/doc/command-reference/remote/add where you can find all the Supported remotes along with basic auth info (in this specific case, S3 by default uses your AWS CLI creds if setup, so ideally no secrets ever exist in the repo) and further links to all the details (here).

@jorgeorpinel But following it specifically requires you to do a dvc push, which requires authenticating to a remote, which in turn will store the auth in the config. Not sure how this works for S3, but that’s what happens in Azure at least.

I have the same question though: if you configured an Azure remote you probably got to https://dvc.org/doc/command-reference/remote/modify#available-parameters-per-storage-type at some point? All the explicit auth setup examples there use --local.

@jorgeorpinel The first two samples, for url and account_name don’t mention --local. The other samples mention it, but you have to scroll for a screen to even see them.

To summarize my position, I wanted to point out what I see as a shortcoming of the docs, especially for beginners who don’t know any better - they will pay even less attention than I did to the fine details, and will end up pushing their connection strings to their closed or open repos.

I realize that different needs have to be balanced here, so feel free to handle this feedback in any way you see fit.

[shcheklein]

Get Started could definitely mention something

@jorgeorpinel yep, but we should control the number of things we mention (e.g. #2969 ). Goal of the get started was always simplicity first. I would consider in this case to improve this part an actual remote and picking Azure from the same page.