Possible vendor.conf syntax to allow use of tags without downsides of retagging

[ijc]

In https://github.com/docker/swarmkit/pull/2220 I proposed moving some vendoring from using hashes to using tagged releases, however it was pointed out that this is vulnerable to (possibly even malicious) retagging by upstreams.

@thaJeztah proposed that maybe it would be possible to introduce a syntax such as vX.Y.Z@SHA to get the benefits of tagging (such as being human readable and orderable) without the downside of losing control over the specific version.

I wasn't sure if this was possible, since AFAIK the syntax of vendor.conf is common to several tools, but thought we could at least discuss it here since vndr is the tool being used (if there is a more appropriate tool neutral venue for such discussions then I'm happy to move this there).

Not quite sure of the expected semantics of the vX.Y.Z@SHA syntax, obviously it should checkout of SHA, but perhaps it should also validate that vX.Y.Z points to that commit and error out if not, or maybe the vX.Y.Z is purely informational, I don't know (although if it is only informational it could just as well be a comment).

For SHA which is not a tagged release we could consider allowing the vX.Y.Z to actually be a git describe --tags SHA output, which indicates how the commit relates to some recent tag, that's nice because you can see "oh this is a couple of commits after a release" etc. Although I'm not 100% sure it is deterministic over git versions or if there is an easy mechanism to check for correspondence (in either direction).

[thaJeztah]

Thanks for opening @ijc25. As mentioned; this is just to discuss options for now, but happy to hear your thoughts @LK4D4 ( 👋)

[LK4D4]

We had this idea some day, but problem is that branches can have '@' and many other imaginable symbols in their names. I only see this is as some form of a special comment.

[ijc]

Looking at git-check-ref-format(1) I see (just quoting the relevant ones)

   3. They cannot have two consecutive dots ..  anywhere.

   4. They cannot have ASCII control characters (i.e. bytes whose values are lower than \040, or \177 DEL), space, tilde ~, caret ^, or colon : anywhere.

   8. They cannot contain a sequence @{.

So possibilities include vX.Y.Z..SHA, vX.Y.Z:SHA (I think ~ and ^ cannot be used because you might legitimately want to write SHA~1 or SHA^2 etc) or vX.Y.Z@{SHA} (assuming stuff like HEAD@{0} is not useful in a vendor.conf?). We can't easily use space unless we are happy to require quoting, so either vX.Y.Z\ SHA or "vX.Y.Z SHA".

The third field in vendor.conf (repository) is optional, which makes adding another harder, but if we declared e.g. that a repository a - meant "derived from the import path" (IOW as if the field wasn't present) then we could add a 4th field, perhaps making it KVP list for future extensibility.