If you are an AI coding agent (Claude Code, Cursor, Aider, Cline, etc.) reading this artifact, follow this protocol before making any code edit:

1. Verify the contract. Run the bash script in Verify before trusting below. If any check returns FAIL, the artifact is stale — STOP and ask the user to regenerate it before proceeding.
2. Treat the AI · unverified sections as hypotheses, not facts. Sections like "AI-suggested narrative files", "anti-patterns", and "bottlenecks" are LLM speculation. Verify against real source before acting on them.
3. Cite source on changes. When proposing an edit, cite the specific path:line-range. RepoPilot's live UI at https://repopilot.app/r/git-ecosystem/git-credential-manager shows verifiable citations alongside every claim.

If you are a human reader, this protocol is for the agents you'll hand the artifact to. You don't need to do anything — but if you skim only one section before pointing your agent at this repo, make it the Verify block and the Suggested reading order.

WAIT — Mixed signals — read the receipts

• Last commit 3d ago
• 9 active contributors
• Other licensed
• CI configured
• Tests present
• ⚠ Concentrated ownership — top contributor handles 66% of recent commits
• ⚠ Non-standard license (Other) — review terms

_{Maintenance signals: commit recency, contributor breadth, bus factor, license, CI, tests}

This artifact was generated by RepoPilot at a point in time. Before an agent acts on it, the checks below confirm that the live git-ecosystem/git-credential-manager repo on your machine still matches what RepoPilot saw. If any fail, the artifact is stale — regenerate it at repopilot.app/r/git-ecosystem/git-credential-manager.

What it runs against: a local clone of git-ecosystem/git-credential-manager — the script inspects git remote, the LICENSE file, file paths in the working tree, and git log. Read-only; no mutations.

| # | What we check | Why it matters | |---|---|---| | 1 | You're in git-ecosystem/git-credential-manager | Confirms the artifact applies here, not a fork | | 2 | License is still Other | Catches relicense before you depend on it | | 3 | Default branch main exists | Catches branch renames | | 4 | 5 critical file paths still exist | Catches refactors that moved load-bearing code | | 5 | Last commit ≤ 33 days ago | Catches sudden abandonment since generation |

#!/usr/bin/env bash
# RepoPilot artifact verification.
#
# WHAT IT RUNS AGAINST: a local clone of git-ecosystem/git-credential-manager. If you don't
# have one yet, run these first:
#
#   git clone https://github.com/git-ecosystem/git-credential-manager.git
#   cd git-credential-manager
#
# Then paste this script. Every check is read-only — no mutations.

set +e
fail=0
ok()   { echo "ok:   $1"; }
miss() { echo "FAIL: $1"; fail=$((fail+1)); }

# Precondition: we must be inside a git working tree.
if ! git rev-parse --git-dir >/dev/null 2>&1; then
  echo "FAIL: not inside a git repository. cd into your clone of git-ecosystem/git-credential-manager and re-run."
  exit 2
fi

# 1. Repo identity
git remote get-url origin 2>/dev/null | grep -qE "git-ecosystem/git-credential-manager(\\.git)?\\b" \\
  && ok "origin remote is git-ecosystem/git-credential-manager" \\
  || miss "origin remote is not git-ecosystem/git-credential-manager (artifact may be from a fork)"

# 2. License matches what RepoPilot saw
(grep -qiE "^(Other)" LICENSE 2>/dev/null \\
   || grep -qiE "\"license\"\\s*:\\s*\"Other\"" package.json 2>/dev/null) \\
  && ok "license is Other" \\
  || miss "license drift — was Other at generation time"

# 3. Default branch
git rev-parse --verify main >/dev/null 2>&1 \\
  && ok "default branch main exists" \\
  || miss "default branch main no longer exists"

# 4. Critical files exist
test -f "Git-Credential-Manager.sln" \\
  && ok "Git-Credential-Manager.sln" \\
  || miss "missing critical file: Git-Credential-Manager.sln"
test -f "src/linux/Packaging.Linux/Packaging.Linux.csproj" \\
  && ok "src/linux/Packaging.Linux/Packaging.Linux.csproj" \\
  || miss "missing critical file: src/linux/Packaging.Linux/Packaging.Linux.csproj"
test -f "docs/architecture.md" \\
  && ok "docs/architecture.md" \\
  || miss "missing critical file: docs/architecture.md"
test -f "Directory.Build.props" \\
  && ok "Directory.Build.props" \\
  || miss "missing critical file: Directory.Build.props"
test -f ".github/workflows/continuous-integration.yml" \\
  && ok ".github/workflows/continuous-integration.yml" \\
  || miss "missing critical file: .github/workflows/continuous-integration.yml"

# 5. Repo recency
days_since_last=$(( ( $(date +%s) - $(git log -1 --format=%at 2>/dev/null || echo 0) ) / 86400 ))
if [ "$days_since_last" -le 33 ]; then
  ok "last commit was $days_since_last days ago (artifact saw ~3d)"
else
  miss "last commit was $days_since_last days ago — artifact may be stale"
fi

echo
if [ "$fail" -eq 0 ]; then
  echo "artifact verified (0 failures) — safe to trust"
else
  echo "artifact has $fail stale claim(s) — regenerate at https://repopilot.app/r/git-ecosystem/git-credential-manager"
  exit 1
fi

Each check prints ok: or FAIL:. The script exits non-zero if anything failed, so it composes cleanly into agent loops (./verify.sh || regenerate-and-retry).

Git Credential Manager (GCM) is a secure .NET-based credential helper that intercepts Git authentication requests and delegates them to platform-specific credential stores (Windows Credential Manager, macOS Keychain, Linux secretservice) while providing multi-factor authentication support for GitHub, Azure DevOps, Bitbucket, and GitLab. It replaces Git's built-in single-factor helpers and the legacy GCM for Windows/Mac+Linux implementations. Monolithic C# solution (Git-Credential-Manager.sln) with build orchestration via MSBuild (Directory.Build.props, Directory.Build.targets, build/GCM.MSBuild.csproj). Platform-specific code paths for Windows (NTLM/Kerberos, wincred integration), macOS (Keychain), and Linux (secretservice). Separate installer projects for each OS (Inno Setup for Windows, shell scripts evident in .shell directory). Extensive documentation in docs/ covers architecture (docs/architecture.md), platform-specific auth flows, and configuration.

Developers and DevOps engineers who use Git with HTTPS remotes against hosted Git services (GitHub, Azure DevOps, Bitbucket, GitLab) and need secure credential storage with MFA support without repeatedly entering credentials or managing personal access tokens manually.

Production-ready and actively maintained. The project has comprehensive CI/CD via Azure Pipelines (.azure-pipelines/release.yml) and GitHub Actions (continuous-integration.yml, codeql-analysis.yml), covers Windows/macOS/Linux with platform-specific installers, and includes code coverage configuration (coverlet.settings.xml). Regular dependency updates via Dependabot (.github/dependabot.yml) indicate active stewardship.

Low risk for core functionality; GCM is a critical authentication path so any bugs affect all Git operations. Single language (C# 1.9M LOC) concentrated in monolithic solution means C# ecosystem dependency quality matters significantly. No obvious abandonment signals, but the project's criticality means careful vetting of updates is essential before upgrading in production environments.

Unable to determine exact current work from provided file list alone, but the structure suggests ongoing effort on platform-specific authentication providers (azrepos-wif.md, azrepos-misp.md indicate Azure DevOps WIF/MISP features), installer improvements (validate-install-from-source.yml workflow), and security scanning (codeql-analysis.yml).

git clone https://github.com/git-ecosystem/git-credential-manager.git
cd git-credential-manager
dotnet build Git-Credential-Manager.sln
dotnet test

Requires .NET SDK (version specified in Directory.Build.props). Use dotnet run after building for local testing.

Daily commands: After dotnet build Git-Credential-Manager.sln, GCM is installed via OS-specific installers (Windows: generated .msi via build, macOS/Linux: shell installers in build output). Local testing: dotnet run --project src/git-credential-manager -- [command] or configure git to use built output: git config --global credential.helper [path-to-built-executable].

• Git-Credential-Manager.sln — Root solution file that orchestrates all projects; understand this first to navigate the codebase structure
• src/linux/Packaging.Linux/Packaging.Linux.csproj — Entry point for Linux platform-specific build and packaging logic; critical for cross-platform deployment
• docs/architecture.md — Comprehensive architectural overview covering credential flow, host providers, and multi-platform design decisions
• Directory.Build.props — Centralized MSBuild properties for all projects; defines common dependencies, versions, and build configuration
• .github/workflows/continuous-integration.yml — CI/CD pipeline definition; shows build, test, and release process for all platforms
• CONTRIBUTING.md — Development guidelines and contribution workflow; essential for understanding code review standards and process
• docs/configuration.md — Complete configuration schema reference; critical for understanding how GCM reads settings and defaults

Add Support for a New Git Hosting Service

1. Create a new host provider implementation following the pattern in docs/hostprovider.md (docs/hostprovider.md)
2. Implement authentication flow based on service capabilities (OAuth, PAT, or custom protocol) (docs/generic-oauth.md)
3. Update configuration schema to include service-specific settings (docs/configuration.md)
4. Add service-specific documentation following pattern of GitHub, Azure, or GitLab guides (docs/gitlab.md)
5. Update build process to include new host provider in release packages (.azure-pipelines/release.yml)

Add a New Configuration Option

1. Document the new option in the configuration reference with valid scopes and values (docs/configuration.md)
2. Update environment variable mappings if applicable (docs/environment.md)
3. Add validation and default value handling in Directory.Build.props or service code (Directory.Build.props)
4. Update CONTRIBUTING.md if this is a user-facing change requiring documentation (CONTRIBUTING.md)

Support a New Platform or OS

1. Create platform-specific directory under src/ following pattern of src/linux and src/osx (src/linux)
2. Create packaging .csproj following Packaging.Linux.csproj pattern for build and distribution (src/linux/Packaging.Linux/Packaging.Linux.csproj)
3. Implement platform-specific credential store backend using available secure storage APIs (docs/credstores.md)
4. Add CI/CD workflow for platform testing and release validation (.github/workflows/continuous-integration.yml)
5. Document platform-specific setup and authentication quirks similar to windows-broker.md or wsl.md (docs/windows-broker.md)

Implement a New Authentication Protocol (e.g., MFA, SAML)

1. Review existing implementations in docs/azrepos-wif.md or docs/bitbucket-authentication.md (docs/azrepos-wif.md)
2. Implement protocol flow following host provider pattern in docs/hostprovider.md (docs/hostprovider.md)
3. Add configuration options for protocol-specific parameters (docs/configuration.md)
4. Document authentication flow and troubleshooting in service-specific guide (docs/ntlm-kerberos.md)

• .NET (C#) — Cross-platform runtime allowing single codebase for Windows, macOS, and Linux with native performance and secure credential handling libraries
• Platform-native credential stores (wincred, keychain, libsecret) — Leverages OS-provided secure storage mechanisms trusted by OS security model; avoids custom crypto and maintains user expectations
• OAuth 2.0 / OpenID Connect — Industry standard for delegated authentication; supports multi-factor auth and reduces need to handle plaintext passwords
• MSBuild + Azure Pipelines — Native .NET build system; Azure Pipelines integrates with Git-ecosystem GitHub org and provides cross-platform build agents

• Single .NET codebase vs platform-specific implementations

  • Why: Ensures consistent behavior and security model across all platforms; reduces maintenance burden compared to separate repos per OS
  • Consequence: Must abstract platform differences (credential stores, UI frameworks); some OS-specific optimizations harder to implement

• Browser-based OAuth flow vs embedded WebView

  • Why: Browser avoids shipping custom OAuth UI code; users see familiar native browser; reduces attack surface
  • Consequence: Requires user interaction and browser availability; slightly slower than embedded flow; copy-paste flow for headless systems

• Configuration via Git config + environment variables vs centralized config file

  • Why: Integrates naturally with Git workflow; per-repository and user-level scopes supported; minimal friction for users
  • Consequence: Requires Git knowledge; distributed configuration harder to audit centrally; environment variables can leak in logs

• Does not implement Git protocol itself; delegates to native Git
• Does not manage SSH keys (uses credential helper protocol for username/password and tokens only)
• Not a package manager or application installer beyond credential helper registration
• Not a continuous integration/deployment orchestration tool
• Does not provide real-time synchronization of credentials across devices
• Not a password manager; only stores access tokens/credentials needed for Git operations

Version management: VERSION file is the single source of truth for all platform builds—updating is non-trivial and affects installers. Platform-specific test requirements: Windows tests need wincred/NTLM available, macOS tests need Keychain access, Linux tests need secretservice—full test suite difficult to run cross-platform locally. Credential storage abstraction: Platform credential stores have different behaviors (timeout, encryption, ACLs)—changes to storage logic must be validated on each target OS. Git configuration parsing: Comments in code reference Git 2.26.2 breaking change (docs reference commit 12294990)—credential config format sensitivity means Git version assumptions are fragile. No obvious local dev setup script: No Makefile or setup.sh visible; new developers must infer MSBuild/dotnet workflow.

• Git Credential Helper Protocol — GCM is fundamentally a credential helper that implements Git's credential helper protocol (stdin/stdout JSON exchange); understanding this protocol is essential to grasp how GCM intercepts and handles authentication requests
• OAuth2 Authorization Code Flow — GCM uses OAuth2 for all hosted services (GitHub, Azure DevOps, Bitbucket, GitLab) to obtain access tokens without storing passwords; the flow involves browser-based login and token exchange
• Platform Credential Storage (DPAPI, Keychain, secretservice) — GCM's core value is delegating to OS-native secure storage (Windows DPAPI/Credential Manager, macOS Keychain, Linux libsecret) rather than plain text—understanding each platform's API and security model is critical for debugging storage issues
• NTLM / Kerberos (Windows Integrated Authentication) — GCM supports NTLM and Kerberos on Windows for Azure DevOps, allowing SSO without explicit credentials—requires understanding of Windows security contexts and token negotiation
• Multi-Factor Authentication (MFA) / Two-Factor Authentication (2FA) — GCM detects MFA requirements from service responses and falls back to browser-based interactive auth—understanding when and how MFA is triggered is essential for supporting all authentication flows
• MSBuild and Central Package Management — The project uses Directory.Build.props/targets and Directory.Packages.props for centralized build config—understanding MSBuild automation is necessary for modifying build process or adding projects
• Cross-platform .NET (Desktop, Console, Runtime Identification) — GCM is built on modern .NET (not .NET Framework) and targets Windows/macOS/Linux with RID-specific executables (win-x64, osx-x64, linux-x64)—understanding runtime selection and platform-specific project configurations is essential

• cli/cli — GitHub CLI (gh) integrates with GCM for credential management and token handling—understanding gh's auth design illuminates GCM's use case
• gitpython/gitpython — GitPython library wraps Git CLI and relies on credential helpers like GCM for authentication—shows downstream consumer pattern
• microsoft/azure-devops-python-api — Azure DevOps Python API is a major consumer of GCM-authenticated credentials; understanding Azure DevOps auth flows helps context
• git/git — Git project itself defines the credential helper protocol that GCM implements; critical for understanding protocol contracts and breaking changes
• microsoft/Git-Credential-Manager-for-Windows — Legacy predecessor project for Windows; GCM is the unified cross-platform replacement consolidating this and Mac/Linux versions

To work on one of these in Claude Code or Cursor, paste: Implement the "<title>" PR idea from CLAUDE.md, working through the checklist as the task list.

Add comprehensive documentation for Generic OAuth provider configuration

The repo has a docs/generic-oauth.md file but the CONTRIBUTING.md and docs/configuration.md lack specific examples for setting up custom OAuth providers. New contributors frequently need to integrate non-standard Git hosting services. Providing step-by-step configuration examples with sample credentials would reduce support burden and improve adoption.

• [ ] Expand docs/generic-oauth.md with real-world configuration examples (GitBucket, Gitea, self-hosted instances)
• [ ] Add a troubleshooting section for common OAuth setup errors in docs/generic-oauth.md
• [ ] Link OAuth configuration prominently from docs/configuration.md's provider section
• [ ] Add example screenshots showing OAuth token generation in docs/img/

Implement validation tests for all credential store backends across platforms

The repo supports multiple credential stores (Windows wincred, macOS osxkeychain, Linux libsecret/gnome-keyring) and the docs/credstores.md file exists but there's likely incomplete test coverage for edge cases like permission errors, missing dependencies, and fallback behavior. This is critical for security and reliability.

• [ ] Add integration tests for credential store initialization failures in the test suite
• [ ] Add tests for permission denial scenarios (read-only keychain, locked gnome-keyring)
• [ ] Add tests for store unavailability and fallback logic across all three platforms
• [ ] Update .github/workflows/continuous-integration.yml to run credstore tests on all platforms (Windows, macOS, Linux)

Add host provider auto-detection validation workflow and documentation

The docs/autodetect.md file indicates host provider detection exists, but there's no dedicated CI validation for detection accuracy across GitHub, GitLab, Azure DevOps, Bitbucket, and custom instances. A validation workflow would catch regressions early and help contributors understand detection logic.

• [ ] Create .github/workflows/validate-host-detection.yml to test provider detection against real repository URLs
• [ ] Add unit tests covering edge cases: SSH URLs, HTTPS URLs, git:// protocols, and non-standard ports for each provider
• [ ] Document the host detection algorithm and priority order in docs/autodetect.md with a decision tree
• [ ] Add test data files in a dedicated test fixtures directory for provider detection test cases

• Add unit tests for credential provider implementations in src/[ProviderName]/Tests/ for untested edge cases in OAuth2 token refresh flows
• Expand docs/architecture.md with sequence diagrams for the credential request → authentication → storage lifecycle for each provider (GitHub, Azure DevOps, Bitbucket, GitLab)
• Create cross-platform integration test suite in .github/workflows/ that validates installer artifacts actually work on fresh VMs (currently only validate-install-from-source.yml visible for source builds)

The Git Credential Manager project demonstrates a reasonable security posture with CI/CD security scanning (CodeQL) and dependency management (Dependabot) in place. However, as a credential storage tool handling sensitive authentication data, several security gaps exist: incomplete SECURITY.md documentation, no visible evidence of code signing for releases, and limited documentation of security testing practices. The project follows security disclosure best practices by having a SECURITY.md file, but it needs completion. For a tool of this criticality, enhanced security documentation, binary signing procedures, and comprehensive threat modeling would significantly improve the security posture.

• Medium · Incomplete Security Policy Documentation — SECURITY.md. The SECURITY.md file appears to be truncated/incomplete. The security reporting instructions are cut off mid-sentence, which could lead to confusion about proper vulnerability disclosure procedures. This is critical for a credential management tool that handles sensitive authentication data. Fix: Complete the SECURITY.md file with full disclosure guidelines, expected response times, and any responsible disclosure timeline. Ensure all contact information is complete and unambiguous.
• Medium · Missing Dependency Vulnerability Scanning Configuration — .github/dependabot.yml, .github/workflows/. While the repository contains .github/dependabot.yml, the actual content of this file is not visible in the provided analysis. For a credential management tool handling sensitive authentication, robust dependency scanning with automated updates is critical. No evidence of SBOM (Software Bill of Materials) generation or vulnerability scanning CI/CD configuration visible. Fix: Ensure dependabot is properly configured to check all NuGet dependencies with automatic PRs for security updates. Consider adding OWASP Dependency-Check or similar tooling to CI/CD pipeline. Generate and maintain an SBOM for each release.
• Medium · No Evidence of Code Signing Verification Documentation — docs/, assets/, .azure-pipelines/release.yml. As a credential storage tool, GCM should implement and document code signing for releases. No visible documentation about binary signing, GPG verification, or checksum validation in the visible documentation structure. Fix: Implement code signing for all release artifacts (Windows MSI/installers, macOS binaries, Linux packages). Document verification procedures for users in docs/install.md and docs/linux-validate-gpg.md. Ensure release.yml pipeline signs all outputs.
• Low · Limited Visible Security Testing Documentation — docs/, .github/workflows/codeql-analysis.yml. While CodeQL analysis is configured (.github/workflows/codeql-analysis.yml), there is no visible documentation about security testing practices, SAST/DAST procedures, or penetration testing reports in the docs directory. Fix: Add comprehensive security testing documentation including: threat models for credential storage, security testing procedures, and results of security audits. Document code review processes for security-critical components.
• Low · No Visible Secure Development Lifecycle Documentation — CONTRIBUTING.md, docs/development.md. For a security-critical component like credential manager, there should be explicit SDLC documentation. While CONTRIBUTING.md exists, there's no visible security development guidelines or secure coding standards documentation. Fix: Expand CONTRIBUTING.md and docs/development.md with: secure coding guidelines specific to credential handling, security code review checklist, and security testing requirements for contributions.

LLM-derived; treat as a starting point, not a security audit.

• Open issues — current backlog
• Recent PRs — what's actively shipping
• Source on GitHub

Generated by RepoPilot. Verdict based on maintenance signals — see the live page for receipts. Re-run on a new commit to refresh.