You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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).
The text was updated successfully, but these errors were encountered:
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.
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.
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 sincevndr
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 ofSHA
, but perhaps it should also validate thatvX.Y.Z
points to that commit and error out if not, or maybe thevX.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 thevX.Y.Z
to actually be agit 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).The text was updated successfully, but these errors were encountered: