いきなりgitが使えなくなった - 2022

Visual Studio Code で Git が動かなくなった

共有フォルダに入っているソースをコーディング中に、なんだかVisual Studio Code (以下VSCode)のソース管理の挙動がヘンだなぁと思っていたら、この画面。

でも .git はあるのよ。だけど この表示。

そこで既存の.gitを .git_に一時改名で退避させて、VSCode のソース管理から[リポジトリの初期化]を行った。

うむ 一応 .gitフォルダは生成された。だが、この画面は変わらず。

コマンドプロンプトから、git init を試みるが「config.lock を原因とするエラー」が吐き出される。

git version は 2.35.3 

OSはUbuntu 20.04LTS

作業時点では最新。

エラー表示だけでは さっぱりわからん。

そうこうするうち WindowsのTortoiseGitでも

共有フォルダはネットワーク越しにNASに入っており、Windowsからも操作できる。

そこでWindows10 から git(およびTortoiseGit)でコミットを試みた。

ところが こっちも拒絶がはじまってた。

TortoiseGit 2.13.0.1

git version 2.35.3

ただこちらでは git init で.git（リポジトリ）の作成はできる。

TortoiseGitのリポジトリ作成でも 問題なく作成される。

しかしコミットが拒絶される。

少しだけ うれしいことに エラー画面にヒントが表示されていた。

git で なにやら設定しろという。

後に判るが この表記には すっごい ワナがあるんだけどね。

問題の切り分け

仮想環境(Oracle VM VirtualBox)の

 Windows7

TortoiseGit 2.11.0.0

git version 2.26.0.windows.1

では本問題は生じなかった。

したがって、ストレージ（NAS）の故障や設定の問題ではない。

異なるOS(Ubuntu Debian GNU/LinuxとWindows)にまたがって生じているので、OSの問題ではない。

異なるバージョン管理ツール(VSCodeとTortoiseGit）にまたがって生じているので、ツールの問題ではない。

つまり git 本体の特定バージョンで生じる問題であることが示唆される。

これがそうだろうか

gitに絞って、それが起きそうな改訂を調べてみたところ、Git security vulnerability announced の 2022/4/12版 で、関係する事象に触れていた。

git利用者が使うディレクトリに .gitフォルダを作りconfigファイルを配置されると、そのconfigファイルの内容によって 最終的に任意のコマンドが自動実行されてしまうおそれがあると。

少しだけ具体的にいえば、複数の人が使うファイルストレージで 悪意を持った誰かがよろしくないファイルを配置すると、それを読み込んだPCが操作できてしまうということね。

（参考）

CVE-2022-24765（CVE）

バージョン管理システム「Git」にセキュリティ上の脆弱性、Git for Windowsユーザーやマルチユーザー環境利用者が取るべき対処法は？（Gigazine）

UACが動作している最近のWindowsで、実際 そういうことできる環境ってあるのかなぁ、というのが率直な印象。

それはともかく。

これってWindowsだけの問題ということになってるけど、gitの実装としては

「そのユーザーが所有しているディレクトリ」だけを

「信頼できるリポジトリの場所」

としたようだ。（参考）

ただその副作用として、所有していない・書き込み権限があるだけのフォルダ、たとえばNAS/クラウドストレージなどの共有フォルダを git 2.35.2からは 使えないようにしたというわけね。リポジトリとしては。

そうなると。

調べてはいないが同一PCであってもマルチユーザーの共有フォルダでgitが使えなくなっているおそれがある。

あと仮想環境（Hyper-VやDockerなど）でホスト・ゲスト間が共有ディレクトリを持っている場合も問題が生じそう。

もしそうだとしたら、なかなか強烈な副作用だね。

きっついなこれは。

このままだとたいへんなので、safe.directory を用いた対応方法を述べる。

Windowsでの緊急対応方法

メモ時点のsafe.directory の説明を読む限りにおいて。

safe.directoryは git 2.35.2から導入されたエントリーでいわばセーフリストを作る手段ということね。

リストに登録されていれば、ユーザーが所有していないディレクトリでもリポジトリが使用できるようになる。

本則は

git config --global --add safe.directory ///nas/www

として、許可するディレクトリを、手元に必要な部分だけ登録することが推奨されている印象だ。

なお、あなたのシステム全体が
「登録上のユーザーは異なるかもしれないけれど(rootとuserなど)」
「使ってる人の生身は同じ」であり、
まちがいなく信頼できるストレージ（リポジトリの場所）で使ってますよということなら

git config --global --add safe.directory *

をコマンドプロンプトで実行すればよいという印象。

緊急時などリスクよりも必要性がうわまわるときだけね。

副作用どころか ワイルドカードで本来の薬効まで中和拮抗（オプトアウト）してしまう荒っぽい方法なので。

書式については、TortoiseGitのエラー表示を見ると、ディレクトリのパスに対して あたかも
「クオートで区切らなきゃいけない」
「冒頭に符合をつけなきゃいけない」
ような説明だが、それをやるとクオートや符合が登録されてしまう。もちろん行そのものが無効になる。

ルールとしては

パスの区切りはスラッシュ（/）で、バックスラッシュや￥は使えない

ホスト名の前は///

といった特徴があるので、Windowsに親しみが強い人はなかなか通らずに苦心するかもしれない。

設定値は

git config --global -l

で表示できる。

消去は

git config --global --unset-all safe.directory

で行える。

まぁ仮想環境をがっつり組んで開発してる人は、何十カ所も書き換えなきゃいけないかもしれないので、たいへんだよね。すぐには対応できないと思うよ。

Windows「以外」の対応方法（git 2.35.3）

Ubuntu の PPAで git 2.35.3 を導入したが、

git config --global --add safe.directory *

が受け付けられない。

バグっぽい。

そこで global を直接書き換えることにした。

まず 先ほど設定した Windows の C:\user\<user name>\.gitconfig を見る。

ini形式で セクション名は[safe]、キー名はdirectory ということがわかった。

こういうの だいたい一緒なんで テキストエディタで

/home/<user name>/.gitconfig

(Ubuntuでは nano ~/.gitconfig など)

を開き

[safe]

directory = *

を追加した。

そして Visual Studio Code でプロジェクトを開いてみると…バッチリ！

一筋縄ではいかなかったが、なんとかソース管理について現状回復できた。

おしまいに

GitHubがらみで何かあるたびに仕事止まるのが嫌だから、ローカルのオンプレミスも使ってクリティカルを避けてるってのに、そのローカルで こういうことあると ヘコむね。

「git入れるなら subversion も並行して入れておけ…」というアドバイスを見かけたことがあるが、なるほど、こういうことがあると それも一理あると思うね。