Skip to content

Attestation init fails: go-git v5.17.1 does not support worktreeconfig extension #2966

Description

@migmartri

Description

After upgrading go-git from v5.16.5 to v5.17.1 (#2961), the Chainloop attestation init step fails in CI with:

ERR initializing crafting state: getting git commit hash: opening repository: core.repositoryformatversion does not support extension: worktreeconfig

Reproduction

This happens in repositories that have extensions.worktreeConfig = true set in their git config (common when using git worktree).

Failing job: https://github.com/chainloop-dev/chainloop/actions/runs/23765321146/job/69243124996

Root Cause

The go-git v5.17.1 upgrade (#2961, merged 2026-03-30) likely introduced stricter validation of git repository format extensions. When a repository has worktreeConfig enabled, go-git now rejects it as an unsupported extension.

Impact

Any CI pipeline using Chainloop attestation in a repository with worktree config enabled will fail at the init step.

Activity

  1. migmartri commented on Mar 30, 2026

    @migmartri
    MemberAuthor

    Root Cause Analysis

    The go-git v5.17.0 release introduced strict extension validation in go-git/go-git#1861. This validation has a case-sensitivity bug that causes it to reject the worktreeConfig extension.

    The bug in go-git

    In repository_extensions.go:

    1. The extensions() function lowercases all extension names via strings.ToLower(opt.Key) → produces "worktreeconfig"
    2. The extensionsValidForV0 allowlist uses mixed case: "worktreeConfig"
    3. Go map lookups are case-sensitive, so extensionsValidForV0["worktreeconfig"] misses the "worktreeConfig" entry → extension appears unsupported

    For repos with repositoryFormatVersion=1 (standard when using git worktree), worktreeConfig also isn't in builtinExtensions at all, so it fails via the ErrUnknownExtension path regardless.

    The chain in Chainloop

    • pkg/attestation/crafter/crafter.go:318 — gracefulGitRepoHead calls git.PlainOpenWithOptions
    • go-git now calls verifyExtensions during open, which rejects worktreeConfig
    • The error propagates up as a hard failure, breaking attestation init

    Fix options

    1. Chainloop-side (short-term): Handle extension errors gracefully in gracefulGitRepoHead — it already degrades gracefully for missing repos/refs (returns nil). The unknown/unsupported extension errors should get the same treatment so attestation can proceed without git metadata.
    2. Upstream (go-git): File a bug about the case-sensitivity issue in extensionsValidForV0 and the missing worktreeConfig support in builtinExtensions.
    3. Pin go-git: Revert to v5.16.5 until upstream is fixed (loses the security fixes from the bump).
  2. added a commit that references this issue on Mar 30, 2026
    134c3aa
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions