Git's SHA-256 default secures nothing you already have

Git 3.0 will ship SHA-256 as the default hashing algorithm. That is the change. A default sets the value Git uses when no algorithm is specified, which makes it a starting condition, not a security control. Treating a default change as a security upgrade is the first error, and this release invites it. The headline reads as a hardening step. What is actually stated is a shift in a default.

Changing the default algorithm does not secure anything that already exists. Every object created before the switch carries the prior identifier, and the security of those objects is unchanged by a new default value. What changes is the cost structure. The migration moves from an explicit decision a team makes to an inherited condition a team receives. Nothing about the existing estate is improved by flipping the starting algorithm for new work.

The claim here is scoped to what the input provides. The input states that Git 3.0 will make SHA-256 the default and frames this as a migration to a new hashing algorithm. It does not confirm the migration path, the interoperability between the two algorithms, the release timeline, or the specific security problem being solved. Those are not confirmed. The absence of that data is itself the exposure. You do not get to assume the safe version of a change the facts have not described.

What is observable is narrow. Git 3.0 sets SHA-256 as the default. It follows necessarily that repositories initialized under Git 3.0 with no override will use SHA-256, and that repositories created before the switch used the prior algorithm. The result is two identifier formats present across the ecosystem at the same time. That coexistence is a direct consequence of a migration between algorithms, not a forecast about adoption.

The identifier is the boundary. In Git, the hash is the object identifier, so changing the hashing algorithm changes how every object is named. A SHA-256 object identifier and a prior-algorithm object identifier are not the same name for the same content. That is logically necessary from the single fact that the algorithm changed. Whether Git bridges the two namespaces, and by what mechanism, is not confirmed in the input. The existence of a safe bridge cannot be assumed from the existence of a new default.

What the default does not do is observable by what the facts decline to state. The input does not confirm that existing repositories are migrated automatically. It does not confirm that old and new repositories interoperate. It does not confirm migration tooling, verification, or rollback. Each of those is not confirmed. A default flip changes the starting algorithm for new work and makes no stated claim about the state of anything that already exists. Read only what is written, and the change is smaller and more one-sided than the framing suggests.

The cost sits in the migration, not in the hash. The strength of SHA-256 is not the variable under control in this change. The variable is identity continuity. When the object identifier algorithm changes, the identity of every object changes with it, and two systems on different algorithms do not share object identity. That breaks the assumption every integration built around Git depends on, which is that an object hash is a stable, portable name for content.

A default is the configuration most systems end up with. Explicit opt-in confines a change to the people who chose it. A default extends it to everyone who does not override it. New repositories, new tooling, and new automation created under Git 3.0 inherit SHA-256 without a decision being recorded. The migration is therefore not a project a team schedules on its own terms. It arrives as the baseline. If a system allows a state by default, that state will occur by default.

The security framing is where this becomes a mistake rather than a tradeoff. The input presents SHA-256 as the new default and raises security implications, but it does not confirm the specific weakness being retired or the guarantee being gained. Not confirmed. A migration justified by an unstated benefit, while carrying a confirmed cost in identity continuity, is a cost you can measure set against a benefit you cannot. That asymmetry is the exposure. The change asks you to absorb a known migration cost in exchange for a security return the facts do not establish.

The failure is not in SHA-256 and it is not in the prior algorithm. It occurs at a single point: where a consumer holds an identifier produced under one algorithm and meets content named under the other. In Git the hash is the object name. The SHA-256 identifier for a given object and the prior-algorithm identifier for the identical object are different strings. Nothing reconciles them unless a reconciling mechanism is stated, and the input does not state one. The break is therefore located precisely. It is wherever a name crosses from one algorithm context into another and is expected to match.

The default is what moves that crossing from rare to routine. A default applies whenever nothing overrides it. Repositories, tooling, and automation created under Git 3.0 with no override produce SHA-256 names without a decision being recorded. Any system that stored, pinned, compared, or transmitted a prior-algorithm identifier now encounters a name it was not built to match. The producers of names change with the default. The holders of names do not, because nothing in the facts migrates them. The mismatch surfaces at the boundary between a system on SHA-256 and a system on the prior algorithm, and Phase 1 established that coexistence of the two formats is a direct consequence of a migration between algorithms.

What would contain this failure is exactly what the input declines to confirm. Interoperability between the two algorithms is not confirmed. An automatic migration path for existing objects is not confirmed. Tooling, verification, and rollback are not confirmed. The mechanism of breakage is therefore delivered without a stated mechanism of containment. The failure point is not bounded by anything in the facts. Absence of a confirmed bridge is not a neutral gap. It is the condition under which the mismatch has nothing to stop it.

The pattern is identifier-as-contract. When a system uses a computed value as both the content fingerprint and the identity, changing how that value is computed changes identity for everything downstream that treated the identity as stable. Every consumer that recorded an object identifier as a durable reference holds a silent dependency on the algorithm that produced it. That dependency was never a stated term. It was inherited the moment the identifier was stored as if it were a permanent name. A change at the identity layer converts that silent dependency into a visible fault.

Delivered as a default, the change reaches two populations differently. It reaches new producers automatically, because the default is the configuration they receive. It reaches existing consumers involuntarily, because they made no change and none was made to the references they already hold. Explicit opt-in would confine the effect to the parties that chose it. A default distributes the effect across the parties that did not. The pattern is not adoption spreading over time. It is a single starting condition applied to everyone who does not override it, which Phase 1 marked as logically necessary from the fact that a default is the state most systems end up with.

The same mechanism is visible anywhere an identifier was recorded as a fixed pointer. A stored reference, a pinned value, or a comparison against an expected hash is matching a name computed under one algorithm. Present the identical content under a different algorithm and the recorded name no longer equals the produced name, even though the content did not change. This is not a separate problem. It is the same mechanism observed at a different consumer: identity computed one way, a dependent still holding the earlier computation. The content is constant. The name is not. The contract that an object hash is a stable, portable name for content is the thing that breaks, and it breaks for every consumer that relied on it without having been told it was conditional.

The operator position is that this is a default shift and must be handled as a migration event, not received as a security control. The cost is confirmed. Identity continuity is the variable under change, and the facts establish that it moves. The benefit is not confirmed. The specific weakness retired and the guarantee gained are not stated. A cost you can measure set against a benefit the facts do not establish is not a hardening step. It is an asymmetry, and treating it as an upgrade is the error Phase 1 named at the start.

What must now be true before the default is trusted is narrow and testable. Interoperability between the two algorithms must be confirmed, not assumed. A migration path for existing objects must be confirmed. Tooling, verification, and rollback must be confirmed. Until those conditions are stated and validated, the safe version of this change does not exist in the facts, and the default must be treated as unenforced. A default is not a control. A control that is not enforced is not a control. Inheriting a starting algorithm is not the same as establishing that the boundary holds across the move.

Identity is the boundary. A change to the identity algorithm is a change to the boundary itself. The facts confirm the boundary moves. They do not confirm anything that holds it together across the move. State it plainly. What failed is identity continuity. Why it failed is that the hash is the name and the name changed. What must be true is a confirmed bridge between the two namespaces before the default is adopted as the baseline. Absent that, Git 3.0’s default is a known cost accepted against a benefit that is not confirmed, and no framing changes which side of that the facts are on.