Why can a release tag stored as its own object be signed, while a tag that is only a name pointing into history cannot?
answer
- Two ways to record the same name
- One is a table line, one is content
- A signature needs bytes to cover
- Ask what the naming act itself stored
basics
~20 sA signature must cover a fixed sequence of bytes. The object form stores real content (target, name, author, timestamp, message), so there is something to sign; a bare table entry has no content of its own.
solid answer
~50 sA release name can be recorded two ways. The cheap form is an entry in the repository's name table: a readable name mapped to a commit identifier, and nothing else. The richer form creates an actual object in the content-addressed store whose bytes record the target, the name, who created it, when, and a message; the name table then points at that object. A cryptographic signature is computed over a specific byte sequence and binds it, so it needs something with stable content. The object form has exactly that — sign it and you bind the name, the target, the author and the message together, and any later change invalidates the signature. The bare form has no bytes of its own to cover, and no record of who wrote the entry, so there is nothing to sign and nothing to verify against later.
go deeper
Know that a release name can be recorded as a bare pointer or as a stored object carrying who, when and why. You are not expected to reason about signatures yet, but you should not claim the bare form remembers anything.
Explain what the object form actually stores and why that content is what a signature can cover. Interviewers are checking that you understand a signature binds bytes, rather than treating signing as a setting that can be switched on anywhere.
Show where the distinction pays off in practice: audits, supply-chain questions, and tracing a suspect release. Be ready to say what your team defaults to for published releases and why the default matters more than the individual choice.
Own the policy: which classes of release must be verifiable, who is accountable when a published release name has no recorded author, and what verification actually runs before a release is consumed rather than merely being recorded.
## Two representations of the same name Both forms of a release name answer the same question — *which commit is this?* — and both resolve to the identical source. What differs is how much of the naming act the repository actually records. 1. **The bare form.** The repository keeps a table of readable names, each mapped to one commit identifier. Creating this kind of release name adds a line to that table. There is no author, no timestamp, no message and no object anywhere in the store that represents the naming act. If someone later overwrites the line, the previous value leaves no trace behind. 2. **The object form.** Creating this kind of release name writes a real object into the content-addressed store. Its bytes carry the identifier of the thing being named, the type of that thing, the release name itself, the identity of whoever created it, the moment they did, and a free-text message. The name table then points at *that object*, which in turn points at the commit. The naming act now exists as durable content, with its own content-derived identifier. ## Why only one of them can be signed A cryptographic signature is a value computed over a **specific sequence of bytes**. Verifying it re-computes over the same bytes and checks that they have not changed and that the claimed signer produced the value. Two things follow: - **You can only sign something that has content.** The object form is a canonical byte sequence, so a signature over it binds *all* of it at once: the release name, the commit it points at, the stated author, the timestamp and the message. Change any of those and verification fails. - **A table entry has no content to bind.** It is a mutable mapping that the repository rewrites in place. There is no stable byte sequence to compute over, nothing an identity could be attached to, and nothing to re-verify a year later. Whoever wrote the entry is simply not recorded anywhere. This is a consequence of the data model rather than a policy choice. The richer form is signable *because* the naming act was stored as content; the cheap form is not signable *because* it was not stored at all. ## What each form can answer | Question about a release | Bare name | Object form | |---|---|---| | Which source did this release come from? | Yes | Yes | | Who decided to cut it? | No record | Recorded | | When was it cut? | No record | Recorded | | Why, in the releaser's own words? | Nowhere to put it | Recorded in the message | | Can authorship be verified rather than trusted? | Nothing to verify | Yes, via a signature | Notice that the first row is identical. The distinction has nothing to do with what content a consumer receives — it is entirely about whether the *act of releasing* is auditable. ## Why the commit's own author is not a substitute A reasonable objection: the commit already records an author and a date, so why duplicate them? Because they answer a different question. The commit's author is whoever wrote the change, possibly weeks earlier and possibly on a different team. Cutting a release is a separate decision, made by a different person, at a different time, and often for reasons that appear nowhere in the code — a promise to a partner, a security embargo lifting, a support commitment starting. The object form is the only place that decision is written down. ## When the cheap form is fine The object form costs a few hundred bytes and one extra piece of information at creation time, so the honest guidance is narrow rather than absolute: - **Private bookmarks are fine bare.** A name you attach locally to find your way back to a point in history, and that never leaves your machine, does not need an audit record. - **Anything a consumer will rely on gets the object form.** The moment a name is published as a release coordinate, someone will eventually ask who produced it and when, and the answer must not be "nobody knows". - **Regulated or supply-chain-sensitive releases need the verifiable form.** Where the question is not merely *who says they cut this* but *prove it*, only a signed object answers. The practical failure is not choosing wrongly on purpose; it is defaulting to the cheap form because it is one step shorter, and discovering eighteen months later — during an audit, or while tracing a compromised release — that the repository can say exactly which source shipped but nothing whatsoever about who shipped it.
- If both forms name the same commit, does a consumer receive different content?No. Both resolve to the identical source, and a build from either produces the same result. The difference is entirely metadata about the release decision: who made it, when, with what stated reason, and whether that claim can be verified rather than merely believed. Choosing the richer form is about auditability, not about what ships.
- Why can nobody recover who created a bare release name after the fact?Because the name table stores only the current mapping from name to commit. Writing the entry leaves no object behind, and overwriting it discards the previous value with nothing recorded about either write. The information was never captured, so it is not a matter of looking harder — there is nowhere it could have been kept.
- A team signs its release names but nobody ever checks them. What has been gained?Very little beyond the authorship and timestamp the object form would carry anyway. A signature only pays off where something verifies it before trusting the release, so the useful step is putting that check in front of consumption. An unverified signature is a record of intent, not a control.
The bare form is a sticky note on a shelf saying which box to take. The object form is a signed dispatch slip filed alongside it: same box, but it also records who sent it, when, and why — and it can be checked for forgery.
saying these in an interview costs you the question
- Thinks both forms record who created the release
- Believes a name-table entry can carry a message or a date
- Says the two forms resolve to different source content
- Assumes signing a release name hides or encrypts its contents
- Treats the commit's author as proof of who cut the release