Weblog entry #81 for dkg
Many projects use simple tag names with the version string like "0.35". This is a plea to ensure that the tags you make explicitly reference the project you're working on. For example, if you are releasing version 0.35 of project Foo, please make your tag "foo_0.35" for security and for future disambiguation.
There is more than one reason to care about unambiguous tags. I'll give two reasons below, but they come from the same fundamental observation: All git repositories are, in some sense, the same git repository; some just store different commits than others.
it's entirely possible to merge two disjoint git repositories, and to have two unassociated threads of development in the same repo. you can also merge threads of developement later if the projects converge.
- Avoid tag replay attacks
- Let's assume Alice works on two projects, Foo and Bar. She wraps up work on a new version of Foo, and creates and signs a simple tag "0.32". She publishes this tag to the Foo project's public git repo.
Bob is trying to attack the Bar project, which is currently at version 0.31. Bob can actually merge Alice's work on Foo into the Bar repository, including Alice's new tag.
Now looks like there is a tag for version 0.32 of project Bar, and it has been cryptographically-signed by Alice, a known active developer!
If she had named her tag "foo_0.32" (and if all Bar tags were of the form "bar_X.XX"), it would be clear that this tag did not belong to the Bar project.
- Be able to merge projects and keep full history
- Consider two related projects with separate development histories that later decide to merge (e.g. a library and its most important downstream application). If they merge their git repos, but both projects have a tag "0.1", then one tag must be removed to make room for the other.
If all tags were unambiguously named, the two repos could be merged cleanly without discarding or rewriting history.
By extension, signing a simple tag is like saying "the source tree in this specific state (and with this specific history) is version 0.3". A close inspection of the state and the history by a sensitive/intelligent human skilled in the art of looking at source code can probably figure out what the project is from its contents. But it's much less ambiguous to say "the source tree in this specific state (and with this specific history) is version 0.3 of project Foo".
Once you start using unambiguous tag names, you make it safe for people to set up simple tools that do automated scans of your repository and can take action when a new signed tag appears. And you respect (and help preserve) the history of any future project that gets merged with yours.
Comments on this Entry
[ Send Message | View dkg's Scratchpad | View Weblogs ]
I'm not arguing for paranoia; i'm arguing for robust systems with predictable and useful behavior, even (in the worst case) despite malicious agents trying to interfere. This is plan-for-the-worst-case engineering. It doesn't actually take much extra work to do it, and the end result is better for everyone.
[ Parent | Reply to this comment ]
[ Parent | Reply to this comment ]
[ Send Message | View dkg's Scratchpad | View Weblogs ]
[ Parent | Reply to this comment ]
git push . v0.15:refs/tags/the-best-release-ever
Oh no! But consider what happens when you verify that tag with "git tag -v": it shows the actual payload that was signed. In other words, it is the annotation (which should certainly explain context) and the content of the commit that git allows a person to sign, not the name used to refer to it.
[ Parent | Reply to this comment ]
[ Send Message | View dkg's Scratchpad | View Weblogs ]
I still stand by my suggestion of choosing unambiguous names, though -- having an unambiguous tag name makes it easier for automated tools which process tags to ensure that they've gotten the right thing (without requiring them to parse the human-readable commentary in tag annotation).
[ Parent | Reply to this comment ]
[ Parent | Reply to this comment ]
[ Send Message | View dkg's Scratchpad | View Weblogs ]
[ Parent | Reply to this comment ]
Otherwise there is just the illusion of security. That a name points to a signed tag means nothing --- in fact, although tag objects store the original name, git allows you to use whatever name you wish to refer to an existing signed tag.
[ Parent | Reply to this comment ]
[ Send Message | View dkg's Scratchpad | View Weblogs ]
The fact that a tag is signed by some arbitrary person shouldn't be relevant; any decent automated system would need to know whose signatures it was looking for, so something signed by Ian Beckwith wouldn't be accepted for a system tuned to look for signatures from Junio C Hamano.
As a developer, i hereby commit to never working on a project with a name that precisely collides with another name of a project i've ever worked on. I don't think this is such a radical position to take. (though maybe Ian Beckwith wouldn't want to adopt it since his project's name was poached by a higher-profile project).
[ Parent | Reply to this comment ]
Many projects use signed tags with annotations that are concise and easy for automated systems to act on. "GNU Interactive Tools 4.3.9" would be an example of a good annotation for humans and computers.
As you just observed, the problem with declaring "I will never work on a project whose name conflicts with another project's" is that you can't always know in advance.
Now, none of what I said above is a reason _not_ to use tags with names like "xorg-server-1.0.1". The only reason I've been repeating this pedantic point is that security requires that your readers understand the system that's being used. Advice that can be easily misread as "please choose an unambiguous name for your git tag refs so the signatures can be more meaningful" has the danger of undermining that. :(
[ Parent | Reply to this comment ]
Moreover, there will be support for remote namespaces for tags, just like branches, conflicts can be solved.
See message-id AANLkTi=yFwOAQMHhvLsB1_xmYOE9HHP2YB4H4TQzwwc8@mail.gmail.com ([1.8.0] Remote tag namespace). (I can't post links)
[ Parent | Reply to this comment ]
Giving tags appropriate names is a good idea, there's no point backing it up with paranoia.
[ Parent | Reply to this comment ]