https://thedotnetblog.com/ja/tags/git/Articles, tutorials and insights from the .NET community.Hugoja@thedotnetblog (The .NET Blog)@thedotnetblogMon, 20 Jul 2026 00:00:00 +0000https://thedotnetblog.com/ja/news/emiliano-montesdeoca/ntlm-git-libcurl-azure-devops-server-action-plan/Mon, 20 Jul 2026 00:00:00 +0000Emiliano Montesdeocahttps://thedotnetblog.com/ja/news/emiliano-montesdeoca/ntlm-git-libcurl-azure-devops-server-action-plan/2026年9月の NTLM 削除は軽微な互換性問題ではない。オンプレミスの Azure DevOps Server 環境にとっての ID アーキテクチャの期限である。<p>libcurl における NTLM 削除の予定は、技術的に見えて実際には組織的な変更である。Azure DevOps Server への Git over HTTPS パスが依然として NTLM に依存している場合、問題はツールではなく、ID 負債である。</p> <p>オリジナルソース: <a href="https://devblogs.microsoft.com/devops/upcoming-change-ntlm-removal-in-git-libcurl-impact-to-azure-devops-server-customers/">https://devblogs.microsoft.com/devops/upcoming-change-ntlm-removal-in-git-libcurl-impact-to-azure-devops-server-customers/</a></p> <p>Microsoft がここで強く推し進めるのは正しい。NTLM には既知の暗号上の弱点があり、現代のエンタープライズのデフォルトであるべきではない。危険な部分は、多くの環境が Kerberos を使用していると信じている一方で、実際には NTLM への SPNEGO フォールバックに静かに依存していることである。その幻想は2026年9月に消える。</p> <p>私の見解:<strong>これを「クライアントバージョン」の問題として扱ってはならない</strong>。NTLM フラグの再有効化、古い Git ビルドの固定、フォールバックが利用可能であり続けることへの期待は、長期的リスクを伴う短命な回避策である。是正戦略がダウングレードと遅延であるなら、あなたは積極的に運用の脆弱性を高めている。</p> <p>実践的な移行シーケンスは、率直で測定可能であるべきである。</p> <ul> <li><strong>今すぐ現在の認証動作を検証する。</strong> 実際の開発者およびビルドエージェントのコンテキスト（オフドメインおよびリモートネットワークパスを含む）で、トレースベースのチェックとチケットキャッシュ検証を実行する。</li> <li><strong>Kerberos をエンドツーエンドで修正する:</strong> SPN、DNS エイリアス、ロードバランサー設定、委任、ドメインコントローラーの到達可能性。</li> <li><strong>非ドメイン参加またはワークグループシナリオを早期に特定し</strong>、Kerberos を確実にできない場所に SSH レーンを設計する。</li> </ul> <p>また、所有権の明確さも必要である。セキュリティチームはポリシーベースラインを定義すべきだが、プラットフォームエンジニアリングが実装の準備責任を持つ必要がある。これは個々のリポジトリ管理者のサイドタスクではありえない。IIS、AD、ネットワークエッジ、CI エージェント、開発者ワークステーションガイダンスにわたる協調的な変更が必要である。</p> <p>ひとつの微妙なリスクは自動化である。ビルドエージェントとサービスアカウントは、人間のユーザーが問題ない場合でも、Kerberos チケットがないか無効なコンテキストで実行されることが頻繁にある。対話型の開発者ワークフローだけをテストすると、最も重要なブレークポイントを見逃すことになる。</p> <p>良い面もある。Kerberos または SSH にクリーンに移行することは、障害を回避するだけでなく、<strong>攻撃対象領域を減らし、ID 制御を最新のコンプライアンス期待値に整合させる</strong>。今この移行を開始するチームは、9月を何でもないこととして扱える。待つチームは、リリース圧力の下で認証障害のデバッグを行うことになる。</p> <p>これはアーカイブするための警告ではない。<strong>それは実行すべき期限である。</strong></p>https://thedotnetblog.com/ja/news/emiliano-montesdeoca/visual-studio-pull-request-review-inside-the-ide/Sun, 21 Jun 2026 00:00:00 +0000Emiliano Montesdeocahttps://thedotnetblog.com/ja/news/emiliano-montesdeoca/visual-studio-pull-request-review-inside-the-ide/Visual Studio は今や IDE を離れずに pull request を最初から最後までレビューできます。これは段階的に見えるかもしれませんが、Visual Studio に一日中いるチームにとっては、不要なコンテキスト切り替えをかなり減らします。<blockquote> <p><em>この記事は自動翻訳されています。原文は<a href="https://thedotnetblog.com/ja/news/emiliano-montesdeoca/visual-studio-pull-request-review-inside-the-ide/">こちら</a>をご覧ください。</em></p> </blockquote> <p>ブラウザは、コードレビューのワークフローからあまりにも長く、あまりにも多くを奪ってきました。</p> <p>だからこそ、Visual Studio が <strong>IDE の中で最初から最後まで pull request をレビューする</strong> 方向へさらに進んでいるのを見るのは、とても嬉しいです。</p> <p>これは大きな見出しを作るタイプの機能ではないかもしれませんが、日々の開発を確実に良くしてくれます。</p> <h2 id="主な価値は単純ですコンテキスト切り替えが減ること">主な価値は単純です。コンテキスト切り替えが減ること</h2> <p>レビューのループが IDE とブラウザの両方にまたがっていると、摩擦が積み重なります。</p> <ul> <li>別の場所で PR を開く</li> <li>あるツールで変更を確認する</li> <li>より深く調べるために solution に戻る</li> <li>コメントや承認のためにまた切り替える</li> </ul> <p>それは致命的ではありません。ただ非効率なだけです。</p> <p>Visual Studio が、同じ作業環境から PR を開き、確認し、コメントし、承認し、マージできるなら、それは本当の生産性向上です。</p> <h2 id="checkout-せずにレビュー-は特にいい機能です">&ldquo;checkout せずにレビュー&rdquo; は特にいい機能です</h2> <p>私が特に気に入っているのは、PR ブランチを checkout せずにレビューできる点です。</p> <p>小さく聞こえるかもしれませんが、次のような場面にぴったりです。</p> <ul> <li>素早いレビュー</li> <li>割り込みベースのフィードバック依頼</li> <li>現在のブランチとローカル状態をそのまま保つこと</li> </ul> <p>これはまさに、優れたコードレビュー ツールに必要な柔軟性です。</p> <h2 id="私見">私見</h2> <p>これは革命的な機能ではありません。</p> <p>もっと良いものです。実用的な機能です。</p> <p>Visual Studio で一日の大半を過ごすチームにとって、PR レビューのサポートが強化されることは、ワークフローの中断を減らし、確認から行動までをより滑らかにします。</p> <p>それは十分に価値のある改善だと思います。</p> <p>原文: <a href="https://devblogs.microsoft.com/visualstudio/review-pull-requests-without-leaving-visual-studio/">Visual Studio を離れずに pull request をレビューする</a></p>