Vscode-remote-release: Git setting core.editor should not be imported into container

[aaronadamsCA]

When I installed Git for Windows, I configured VS Code as my default editor.

Local Windows shell:

PS > git config --global core.editor
"C:\Users\AaronAdams\AppData\Local\Programs\Microsoft VS Code\Code.exe" --wait

Unfortunately when I build a dev container, it seems the ~/.gitconfig file that gets created imports the core.editor setting from Windows.

Remote shell:

$ git config --global core.editor
"C:\Users\AaronAdams\AppData\Local\Programs\Microsoft VS Code\Code.exe" --wait

This results in shell sessions within the container attempting to call code using its Windows path, leading to fun error messages like this one:

$ git rebase -i 898e0b1
hint: Waiting for your editor to close the file... "C:\Users\AaronAdams\AppData\Local\Programs\Microsoft VS Code\Code.exe" --wait: 1: "C:\Users\AaronAdams\AppData\Local\Programs\Microsoft VS Code\Code.exe" --wait: C:\Users\AaronAdams\AppData\Local\Programs\Microsoft VS Code\Code.exe: not found
error: There was a problem with the editor '"C:\Users\AaronAdams\AppData\Local\Programs\Microsoft VS Code\Code.exe" --wait'.

git config --global core.editor "code --wait" solves the problem, I assume until the next container rebuild.

Generally speaking I don't think all Windows .gitconfig settings should be valid for import (winUpdater.recentlySeenVersion also strikes me as irrelevant, for example). Specifically I think at least core.editor should be blacklisted for import.

[aaronadamsCA]

Note this also applies to a couple of other settings, including core.autocrlf and core.sshCommand, that cause additional problems of their own.

I wonder if the import should be limited to user.name and user.email by default.

[kaytwo]

This bug is still stinging me (and some of my students). The least annoying workaround for now seems to be:

• remove core.sshCommand from your Windows .gitconfig
• set GIT_SSH environment variable in Windows to C:\Windows\System32\OpenSSH\ssh.exe (make sure you have native ssh installed)
• remove core.editor from Windows .gitconfig
• deal with vim on windows / update-alternatives editor of choice on linux when running git commit from the command line. This isn't a dealbreaker for me because I will typically either run git commit -m'message' from the command line or use the vscode git gui to write a longer message.

[chrmarti]

We need a setting to turn this off. As a temporary workaround you could configure at dotfiles repository in your user settings that sets up a .gitconfig in the user's home folder. We do not overwrite existing .gitconfigs.

[aaronadamsCA]

My current workaround is to remember to run these 5 commands after every container rebuild:

git config --global core.editor "code --wait"
git config --global core.autocrlf input
git config --global --unset core.sshCommand
git config --global user.name "Aaron Adams"
git config --global user.email [email protected]

With the right documentation I'm sure dotfiles could be a good solution, just be mindful that different containers may require different users (you probably don't want to use your microsoft.com email on your personal projects, nor your personal email on your work commits). Some supported/documented means of having user.name and user.email be container-specific + survive rebuilds would be ideal.

[sanmai-NL]

I do not think the auto-copying of partial settings and therefore any settings at all is worth the trouble. It's perfectly possible to mount the git config into the container for those developers who wish to. Rather than creating a feature for this I'd rather see you document how to do this as a FAQ/advanced tips entry, @chrmarti.

[PavelSosin-320]

I fully agree with @sanmai-NL sanmi-NL !
I don't think that the implementation of a convenient git configuration requires any design because the standard implementation exists Alpine/git and the very impressive number of pulls of this implementation which is shown at the upper right corner of the web page confirms its correctness.
There is no reason to built-in git configuration into every dev container when it can be done once and then bind-mounted or Docker volume mounted to every container at start-up time.

[PavelSosin-320]

Thinking twice before creating or copying any private information in the docker image or running docker container!!!
This information can be hijacked in terms of seconds by any person who can achieve access to the repository to which the image will be published or the Docker engine which runs the container using Extract docker image filesystem into the file. Don't cry after it!
The artifacts which can be secured in the Docker infrastructure are Volumes and Secrets.

[Chuxel]

I do not think the auto-copying of partial settings and therefore any settings at all is worth the trouble. It's perfectly possible to mount the git config into the container for those developers who wish to. Rather than creating a feature for this I'd rather see you document how to do this as a FAQ/advanced tips entry, @chrmarti.

@sanmai-NL Mounting configuration files on Windows is often not a good idea due to problems with permissions (e.g. early on we had to document hack workarounds for the .ssh folder). This also precludes the extensions use with containers that are on remote hosts. As a result we cannot make that recommendation across the board.

[PavelSosin-320]

@sanmai-NL The Configuration volume is the solution provided and recommended by Docker across its orchestration engines because it fulfills a long list of requirements like:
I would like to have 1 configuration both for my local and containerized git and test it locally 1st
I would like to to have my configuration persistent locally and remotely regardless of the ephemeral lifecycle of the Docker container (Docker volume), I would like to create my own tenant of configuration locally and copy it into the running container using the Docker CP command as a whole or partially
I would like to protect my configuration containing ssh keys on the remote host from other users who have access to this host using the Docker security mechanism only (Docker running on SELinux server, like Ubuntu 20.04), etc....

Read access to .ssh folder should be permitted only to the Admin group and User running the Docker daemon if Docker containers will need to read its content. Playing with Image / container user will work well on Linux but can be too complex on Windows, but it is Docker problem, not VSCode. Windows folder permissions shall be propagated correctly to Docker Desktop distro.
ls -al /mnt/c/Users/Pavel/.ssh

Expected Output ??????? :
drwxrwxrwx 1 pavel pavel 4096 Jun 17 18:40 .
-rwxrwxrwx 1 pavel pavel 2635 Jun 17 18:04 id_rsa
-rwxrwxrwx 1 pavel pavel 564 Jun 17 18:04 id_rsa.pub
-rwxrwxrwx 1 pavel pavel 172 Jun 17 18:03 known_hosts

[cecilemuller]

I'm having a similar issue/use case, with signed commits: I have to define gpg.program in Windows (otherwise Git uses a different gpg and keyring than the ones from Gpg4win), but don't need this setting in containers.

[chrmarti]

Adding a setting to disable copying of the .gitconfig.

[sanmai-NL]

@chrmarti Thanks! Could you please provide a general setting that also prevents .ssh etc. from being copied?

[PavelSosin-320]

@sanmai-NL Remark: Dockerfile is used to build images, not containers. After something is written into the image then everybody can create and run a container using this image, with your keys Sorry, absolutely zero protection. Somebody else can create another container using your image using the same volume bind and freely use your keys, by mistake.
is it a problem? No!
If I created my personal sanmai "Configuration volume" I will always run my image with the option --user sanmai and
mount the sanmai condiguration volume to /the /home/sanmai in the container.
In such a way my configuration is fully personalized.
Is it OK for you?

[sanmai-NL]

@PavelSosin-320: I understand what you‘re saying and I have agreed with you all along. I propose to not copy any settings into the container. A secrets volume is the way to go, perhaps VS Code can help with this. But I have been arguing so far, that this kind of customization is better left to the users, based on some guidance. Automating this seems rather tricky. E.g, which paths to include, where to mount, etc.

[chrmarti]

@sanmai-NL The only other file we currently copy into the container is .ssh/known_hosts to not block on unknown hosts. Could you open a new issue for your request? Thanks.

[PavelSosin-320]

Yes, I propose to follow the standard Software and Docker development technic - separation of code and configuration.
If there is no need for security hardening today it is easily possible.
The configurable set of configuration dot files and folders will always restrict a user from using additional tools because every tool will bring its own configuration files, folders, and security artifacts and every dotfile will require some code. Then users will stop to use the tool but configuration dot files, folders, and code will retain n VSCode forever. A simple upgrade of the tool will create a new image that can be tried only once. No support team can afford such an unlimited growth of support workload.
On other hand, every installer and installation procedure today creates all necessary dotfiles and folders, well known to developers, disappearing when the tool is uninstalled. Users can adjust and personalize configuration during the project lifetime, create and populate, create again, and refresh volumes but images can't be re-created or refreshed in such a simple way.
I don't talk about security, I talk about simple configuration personalization.

[PavelSosin-320]

Or incorporated in another way Passing secure information to image in the recent Docker versions

[aaronadamsCA]

Adding a setting to disable copying of the .gitconfig.

@chrmarti, do you have a link so I can keep track of release? I'm ramping up a dev team right now, and I'd like to take advantage of this new setting as soon as it's out to reduce confusion. Thanks.

[PavelSosin-320]

"Enable" copying .gitconfig denies from user to use standard --user option of docker run command. It may cause unpredictable side effects related to volume access including "bind" anonymous volumes on Linux.
Although USER is a Dockerfile parameter it defines only the default value. It can be overridden during the running of the created image to satisfy Docker security constraints.
Every time when a part of a user's profile is integrated into the Docker image it will end either the backdoor creation or access issues.
It always contradicts Docker's container isolation concept!
Docker image has no ownership.

[chrmarti]

@aaronadamsCA It is available with VS Code Insiders and will be available with the upcoming VS Code 1.51.

[aaronadamsCA]

@chrmarti FYI, with Code 1.51.0, setting "remote.containers.copyGitConfig": false in .vscode/settings.json appears to have no effect. .gitconfig is still copied from Windows on container rebuild.

[chrmarti]

@aaronadamsCA I mistyped: It will be available with VS Code 1.52. Currently available with VS Code Insiders.

[aaronadamsCA]

Got it, thanks @chrmarti.

It looks like the setting itself went out with 1.51, which is why I thought it would work:

[chrmarti]

@aaronadamsCA Checked again and you're of course right. I see you have placed it in .vscode/settings.json, that is not read during early startup when the setting is needed. Try disabling it in the user settings.

[aaronadamsCA]

Ah, shoot. Good to know. I do want it as part of the container definition, would that be a new ticket? Seems like a "bug" if the setting can exist without doing anything.

For anyone else looking for a solution, my (awful) workaround for now:

.devcontainer/devcontainer.json

  "postCreateCommand": "npm install; git config --global --remove-section core; git config --global --remove-section user; git config --global core.editor \"code --wait\"",

This should generally take care of the worst of the settings that get imported from Windows or Mac into WSL (I've got Windows, Mac, and Linux devs all working from the same Ubuntu dev container).