kanaria007 PRO

Yes. The rejection does run over both files in the allowed configuration closure when worktree config is enabled.

The current implementation performs include detection once against the qualified repository-local source and, when extensions.worktreeConfig=true, again against the qualified config.worktree source using --worktree.

So your exact fixture is already rejected before the final effective core.bare / core.worktree query is trusted.

What your example exposed was a gap in my evidence surface rather than another implementation gap.

I already had these cells pinned separately:

local config × include.path
local config × includeIf.*.path
config.worktree × include.path

but I did not have the fourth interaction cell pinned directly:

config.worktree × includeIf.*.path

I have added that missing fourth-cell witness now.

The fixture writes mixed-case:

[IncludeIf "gitdir:<root>/"]
Path = <included file>

into config.worktree, with the included file setting core.bare=true.

Before checking Profile A's verdict, the test independently establishes three things with Git itself:

git config --worktree --get-regexp '^(include|includeif)\.'

matches the mixed-case declaration and reports the key back as lowercase includeif...;

git config --worktree --includes --bool --get core.bare

returns true;

and ordinary effective config also returns true.

Only after those preconditions are established does the test require Profile A to reject the worktree config as an unsupported include representation.

So the case-normalization assumption is pinned too. The detector deliberately passes the lowercase regex

^(include|includeif)\.

to Git, and the new witness now establishes directly that this query catches the mixed-case spelling used in the file, rather than leaving that behavior implicit.

The distinction I would make after this round is:

implementation covers the declared source closure
!=
the test matrix demonstrates every interaction inside that closure

The first was already true for this case. The second was not.

Your fixture prompted me to audit that interaction matrix, which exposed the missing fourth cell.

Yes, that question exposed that my previous description was too strong.

The strip list was not closed over every route that can reach Git configuration. GIT_CONFIG_PARAMETERS was indeed missing, and treating the existing list as “the Git Authority/config override surfaces” overstated what it actually established.

I also do not think the right replacement boundary is “everything currently demonstrated to change the ls-files --sparse -z answer.”

I still do not have a GIT_CONFIG_PARAMETERS key that changes the tracked-path set of the full-index fixture, so I am not claiming that witness.

Instead, I followed the broader question you raised: what configuration sources are allowed to participate in interpreting Profile A's local Git Authority at all?

That turned up two additional gaps with no ambient environment variable involved.

First, extensions.worktreeConfig=true can make config.worktree participate in effective configuration. I reproduced:

local core.bare=false
worktree core.bare=true

where git config --local --bool --get core.bare reports false, but ordinary effective config reports true.

Second, a repository-local include.path can produce the same split: the direct local file says core.bare=false, while an included file says true. A --local query without include-following sees only the former; effective Git configuration sees the latter.

Neither fixture changes the full-index ls-files --sparse -z path set as constructed. The issue is the qualification/consumption interpretation mismatch itself.

So I changed the Profile A boundary from a variable-strip list to a configuration-source closure.

The allowed configuration sources are now:

• the qualified repository-local config;
• the qualified worktree config when extensions.worktreeConfig enables it.

System, global/user, command-scope, and environment-injected config are excluded from the Authority interpretation context.

That means GIT_CONFIG_PARAMETERS and GIT_CONFIG are stripped, while system/global scope is deliberately bound to a known-empty source rather than merely removing caller overrides and falling back to the host's real configuration.

Config include / includeIf is currently rejected as an unsupported representation rather than recursively followed, because it introduces another configuration dependency outside Profile A's qualification closure.

There were two more subtleties while implementing that.

One was the same:

qualified container
!=
qualified consumed object

pattern again.

Qualifying the git-dir does not qualify its config file. I confirmed that an ordinary .git/config symlink to an external file is transparently followed by Git, so the actual local-config pathname is now qualified before any Git config query reads it.

For a linked worktree, that actual local-config source is not <private-gitdir>/config; Git reads the common Git directory's config. The common-config locator is therefore the object Profile A qualifies there, while the per-worktree config.worktree, when enabled, remains attached to the private gitdir.

The other subtlety was config precedence. My first implementation switched the final binding check from --local to --worktree when worktree config was enabled. That was also wrong: --worktree is worktree-only, not a merged local+worktree view.

For example:

local core.bare=true
worktree core.bare=unset

gives:

--local → true
--worktree → unset
effective config → true

So the final core.bare / core.worktree verdict now uses Git's unscoped effective configuration, but only after the allowed local/worktree sources have been qualified and every other config source has been closed. That lets Git perform its own precedence merge rather than Profile A trying to reproduce it.

The resulting boundary is roughly:

qualified Authority object
+ qualified allowed configuration sources
+ closed configuration-source universe
+ Git-native effective merge semantics
→ qualified interpretation context

The focused Git Authority suite is now 81/81 with these source-closure cases pinned.

So the answer to your original question is now: neither “only what I have already shown changes the answer” nor “arbitrarily everything that can reach config.”

The intended closure is over the configuration sources Profile A permits to participate in Authority interpretation. Individual environment variables are then just carriers that either belong inside or outside that declared boundary.

Your GIT_CONFIG_PARAMETERS example was what exposed that the earlier abstraction had not actually reached that closure yet.

That exact shape is already one of the reasons Profile A sanitizes the Git subprocess environment.

The answer to your last question is: neither.

Profile A does not build a minimal environment from scratch, but it also does not inherit the caller environment and assume the Git variables are clean. It copies the inherited environment and explicitly removes the Git Authority/config override surfaces before the Git subprocesses that establish or consume local Authority.

That includes:

GIT_DIR
GIT_WORK_TREE
GIT_INDEX_FILE
GIT_COMMON_DIR
GIT_OBJECT_DIRECTORY
GIT_ALTERNATE_OBJECT_DIRECTORIES

plus GIT_CONFIG_COUNT and indexed GIT_CONFIG_KEY_n / GIT_CONFIG_VALUE_n.

GIT_INDEX_FILE specifically is there because I reproduced the same property earlier: explicit --git-dir and --work-tree do not override it, so a foreign index can otherwise substitute the tracked-path set after the nominal git-dir has already been qualified.

In the current Profile A implementation, both Git subprocess call paths use the same _git_authority_subprocess_env() helper: the final git ls-files --sparse -z call and the git config --local calls used during Authority qualification. So qualification and consumption use the same environment-isolation policy.

There is also a regression test for the GIT_INDEX_FILE case, and I kept it after switching the final query to --sparse, specifically to make sure this hardening did not regress.

Your witness does add a useful general point, though:

clean rc + clean stderr + supported output representation
!=
consumer used the qualified Authority

In this case there is nothing in the consumer's result channels that can tell us afterward which index Git actually read. The foreign one-entry index produces a perfectly plausible successful answer.

So this is another case where trying to infer Authority from the consumer's output is too late. The Authority-selection surface has to be constrained before the consumer runs.

That is also why I treat environment sanitization as part of Authority binding rather than as output validation.

Only on the sparse representation it knows about. Profile A does not currently fail merely because the Authority query wrote something to stderr.

I do not think non-empty stderr is the right semantic boundary.

The sparse-index bug showed:

rc == 0
!=
Authority observation completed

but I do not think the replacement rules are:

stderr empty
=>
Authority observation completed

or:

stderr non-empty
=>
Authority observation incomplete

In other words:

diagnostic channel state
!=
Observation status

stderr is a diagnostic channel whose semantics are specific to the operation and diagnostic being emitted. Promoting the channel itself into an Observation-status signal would just replace one coarse proxy with another.

So the sparse fix deliberately uses evidence about the representation rather than stderr:

git ls-files --sparse -z
→ sparse-directory entry observed
→ completing the pathname set would require object-store expansion outside Profile A's qualification closure
→ reject the representation before accepting any returned path

That gives Profile A a semantic reason for rejecting the result that is tied to the Authority dependency itself, rather than to the channel Git happened to use to report a problem.

I think the more general lesson from the exit-0 case is therefore:

process status
!=
Observation status

What Profile A really needs is a semantic distinction closer to COMPLETE / INCOMPLETE / UNSUPPORTED / UNAVAILABLE. The subprocess interface does not provide that distinction directly, so treating stderr non-empty as INCOMPLETE would still be an inference unless that contract can be established for the specific Git operation.

That is why I would not add a blanket stderr rejection here without a reproduced case showing that Profile A currently accepts an incomplete Authority result that its existing representation boundary does not catch.

The broader reason I care about this distinction is that conventional computing interfaces expose coarse machine-facing signals and representations — exit codes, stderr, exceptions, byte streams — while the semantic distinctions a reasoning layer actually needs often have to be reconstructed above them. If those reconstructions are allowed to harden into facts without an explicit evidence boundary, the next inference can build on a state that was never actually observed.

That concern is also part of why the wider SI work keeps separating Authority, Observation status, provenance, and claim boundaries, and why some of it reaches below the model/runtime layer: not to make lower layers “understand meaning,” but to preserve more of the distinctions that higher layers would otherwise have to infer back into existence.

So for now, stderr is evidence worth investigating, but not itself the Authority verdict.

Profile A does not qualify repository-local objects/info/alternates today. The claim stops before that object-store edge.

It does strip GIT_ALTERNATE_OBJECT_DIRECTORIES from the inherited environment, but that is invocation hardening against an ambient override, not qualification of .git/objects/info/alternates itself.

Your question did expose one place where I had accidentally crossed that boundary, though.

For a non-sparse index representation, ls-files does not need sparse-directory tree expansion to materialize the tracked pathnames. A genuine sparse index is different: a sparse-directory entry can require Git to read a tree object from the object store in order to expand it into the contained paths.

I reproduced a bad consequence of that distinction with real Git. With the tree object needed to expand a sparse-directory entry removed, plain:

git ls-files -z

reported errors on stderr but still exited 0, with the paths beneath that directory silently absent from stdout.

So my previous Profile A path observation had a hidden object-store dependency in the sparse-index case. Exit 0 was not proof that the tracked-path observation was complete:

Git subprocess succeeded
!=
Authority observation completed

I changed the final Authority query to:

git ls-files --sparse -z

so Git reports a sparse-directory entry directly rather than expanding it through the object store. Profile A now rejects any such entry as an unsupported Authority representation before accepting any part of the returned path set.

Importantly, it rejects a healthy sparse index too. This is not a missing-object detector. The representation itself is outside Profile A because accepting it would make the tracked-path set depend on object-store state that Profile A does not qualify.

An ordinary non-sparse index produces the same path set through --sparse, and a real split-index repository remains accepted, so the restriction is specific to the representation that introduced the reproduced hidden dependency.

So the boundary I would state now is:

qualified git-dir + qualified supported index representation
!=
qualified Git object store

Profile A does not currently inspect objects/info/alternates, and I do not think it should merely because that edge exists. For the path-Authority operation Profile A accepts, the goal is instead to avoid requiring sparse-tree object-store traversal at all.

If a future accepted representation or consumer makes the Authority result depend on objects or alternates, then that dependency would need either its own qualification closure or an explicit unsupported-representation boundary. The sparse-index case turned out to be the latter.

Your re-parenting result also sharpened the descriptor-mode point for me: resolving a dependency once and giving the consumer the resolved objects is stronger than trying to classify every path spelling through which it might later be re-resolved. But that remains a separate stronger local mode, not a change to Profile A.

Yes, that correction is important. relative was too coarse a candidate admission condition.

Your row 4 makes the distinction clear:

same anchored starting object
+
same destination inode
!=
same resolution semantics

../.. preserves the anchor because it is a pure ancestor walk from the already-open directory. ../../../../main/.git is also relative, but once it introduces a forward name component it re-enters mutable name lookup, so the descriptor anchor no longer carries through that edge.

So the relevant property is not relative. For the concrete shape you measured, it is closer to:

pure ancestor traversal only

or, at the more general assurance level:

anchor preserved across this metadata-defined edge

That is a better predicate than the one I sketched.

On your last question: Profile A does observe the raw commondir value while processing the relationship. The commondir file itself is qualified first, then its contents are read. A relative relationship is joined onto the already-qualified private gitdir without normalizing first, and that still-lexical path is walked component by component before normalization is used for the binding comparisons.

But Profile A does not retain the shape of that relationship as a downstream assurance fact.

After the walk succeeds, the path is normalized for the existing binding comparisons, and linked-worktree qualification ultimately returns the qualified private gitdir rather than something like:

commondir_edge = PURE_ANCESTOR_WALK

So rows 1 and 4 are distinguishable while the current relationship is being processed, but that distinction is not preserved as reusable evidence for a hypothetical stronger mode.

I think that reinforces the decision not to add a new admission rule to Profile A now.

If I had added commondir must be relative after the previous round, it would have done two bad things at once: reject otherwise-supported layouts and still fail to establish the temporal property it appeared to promise. A missing stronger-mode condition is better than a plausible-looking but insufficient one.

So I am leaving the current implementation and documentation unchanged. Profile A still makes only its existing point-in-time pathname claim.

If a descriptor-bound mode is ever implemented, I would treat this as a separate edge-semantics classification problem: observe the raw relationship, classify whether traversal preserves the anchor without fresh name lookup, retain that classification as evidence, and admit the stronger mode only on the edge shapes it actually knows how to bind.

Your row 4 is the useful counterexample here because it separates endpoint identity from transition semantics. The destination can be identical while the assurance property changes entirely with how the path gets there.

Yes, Profile A already reads commondir as metadata rather than treating it as an opaque locator.

The file itself is qualified first, then its contents are read. A relative value is joined onto the already-qualified private gitdir without normalizing first, the resulting lexical path is walked component by component, and only afterward normalized for the binding comparisons. An absolute commondir is also supported, but is treated as an independent metadata-derived locator and walked from the filesystem root.

So technically I could add something like commondir must be relative, or even require the canonical linked-worktree ../.. relationship.

I do not think I should add that to Profile A, though.

Your latest witness exposes a more important distinction:

descriptor-anchored private gitdir
!=
descriptor-anchored Authority chain

Whether the anchor propagates across the commondir edge depends on that edge's resolution semantics. With Git's normal relative ../.., the relationship happens to preserve the anchored ancestry. With an absolute value, resolution leaves that anchored chain and returns to pathname lookup.

That makes the strengthening more interesting, but also makes me less inclined to fold it into Profile A.

Requiring relative or canonical commondir today would narrow the set of otherwise-valid Git layouts Profile A accepts, not because the current pathname-based guarantee needs that restriction, but because a possible future descriptor-bound implementation would benefit from it. I would rather not let requirements from an unimplemented stronger mode leak backward into the baseline profile.

More generally, I think your experiment identifies the actual boundary more cleanly than the Linux portability discussion did:

anchor at one node
!=
anchor preserved across every metadata-defined edge

A stronger profile would therefore need to specify both the execution primitive and the metadata-edge resolution semantics across which identity preservation is claimed. Otherwise the strength of the guarantee would silently depend on a favorable representation of metadata whose resolution behavior is itself part of the Authority chain being qualified.

So I am keeping the current implementation and documentation unchanged here. Profile A remains point-in-time and pathname-based; relative and absolute commondir remain supported and explicitly qualified under that contract.

If a descriptor-bound local mode ever becomes justified, I think canonical relative commondir would belong there as an explicit admission condition, together with the platform and consumer-binding requirements — not as a new restriction on Profile A.

Your absolute-vs-relative witness is useful precisely because it shows why that separation matters.

That measurement changes my implementation-cost estimate, but not the Profile A boundary.

First, to answer your last question: yes, there is one other subprocess shape in Profile A. Besides the final git ls-files, _qualify_git_directory_binding() passes an already-qualified git-dir pathname to the git config --local subprocesses used to inspect core.worktree and core.bare. That applies to an ordinary .git directory and to the common/main git-dir requalified during linked-worktree validation. I did not find another subprocess consumer in repo_integrity.py.

--work-tree=<root> is also a pathname, but I treat that differently here because the caller-supplied root is Profile A's explicit trust anchor rather than a Git-metadata-derived locator.

Your timing result is useful for another reason: in your fixture, it confirms that moving another pathname revalidation closer to exec would buy very little. The dominant measured window is the process boundary, not the checks being performed while the private-gitdir pathname is retained. So the earlier categorical point — another lstat() can reduce a window without changing the guarantee class — now has a concrete measurement behind it.

And the /proc/self/fd/N witness is a good correction to my implementation-cost intuition. For the private-gitdir handoff specifically, on Linux, descriptor anchoring across the Git exec boundary is substantially more local than I had assumed.

I still would not make that stronger guarantee part of standard Profile A, though.

The reason is portability of the assurance contract rather than whether the Linux mechanism works. If descriptor-anchored handoff became something Profile A itself claimed, then equivalent temporal-binding machinery would be needed across the platforms on which Profile A is meant to retain the same meaning. The Linux shape depends on facilities and execution details such as /proc availability, fd inheritance across exec, no-follow descriptor traversal, and the surrounding container/sandbox environment. Other platforms would need different machinery, and future Git/OS combinations would become another compatibility surface to qualify.

Otherwise we would create a new ambiguity:

same Profile A result
!=
same claimed temporal assurance semantics

I would rather keep the profile label invariant than make its temporal guarantee conditional on which host happened to run it.

Also, as you noted, anchoring the private gitdir closes that particular pathname-substitution boundary; it does not by itself anchor every object Git subsequently resolves from that directory. The git config --local subprocesses expose the same distinction from another angle: anchoring the git-dir handed to Git is not automatically the same as retaining descriptor-bound identity for every config/index/object Git later opens beneath or beyond it.

So my current stopping point is:

• keep standard Profile A portable and pathname-based;
• keep concurrent hostile namespace mutation as an explicit non-claim;
• treat descriptor-anchored handoff as a possible platform-specific strengthening, or as a separate stronger profile/layer if a concrete use case eventually justifies the additional compatibility surface.

Your witness definitely makes that strengthening look cheaper on Linux than I originally expected. It just does not make the cross-platform assurance contract equally cheap.

Yes, I traced the actual consumption topology, and the answer is mixed.

Some metadata files are consumed almost immediately after qualification: commondir and the private gitdir back-binding are qualified and then read directly.

But the private-gitdir locator itself is reused. A qualified linked-worktree private gitdir is retained while the checker performs the commondir, common/main-root, config, and back-binding checks, and that same pathname is later passed to the final git ls-files subprocess. The qualified index is likewise qualified by pathname, but Git later reopens it through the gitdir rather than consuming a descriptor-bound object retained from that qualification.

So this is not a design where every qualification-to-consumption gap is adjacent or uniformly tiny. Your gap experiment therefore applies to Profile A in a concrete way, not just as a theoretical caveat.

At the same time, I think it confirms rather than contradicts the boundary we had already reached:

point-in-time pathname qualification
!=
race-free temporal binding

I considered adding another pathname revalidation near the final consumer, but that would only reduce the window without changing the guarantee class. A proper stronger claim would require qualification and final consumption to remain attached to the same descriptor-anchored object identity — including across the Git consumer boundary — which is a different design layer rather than another lstat() hardening pass.

So I am leaving the implementation unchanged and making the temporal boundary explicit in the tooling documentation, including the fact that some qualified locators are retained and reused later in the run.

I think that is the right stopping point for Profile A: the lexical walk turns a persistent plant-and-wait path substitution into a race, which is a meaningful mitigation, while concurrent hostile namespace mutation remains an explicit non-claim rather than something the profile quietly implies it solved.

And yes, the rare-event result is a useful warning in its own right. A single zero-hit run would have been very easy to mistake for evidence of impossibility.