Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Open
ijc opened this issue Jun 7, 2017 · 3 comments

Comments

@ijc
Copy link
Contributor

ijc commented Jun 7, 2017

In moby/swarmkit#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
Copy link
Collaborator

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

@LK4D4
Copy link
Owner

LK4D4 commented Jun 7, 2017

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
Copy link
Contributor Author

ijc commented Jun 12, 2017

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants