On Tue, Jun 07, 2016 at 02:05:20PM -0700, Junio C Hamano wrote: > santiago@xxxxxxx writes: > > > 1.- Using a tag ref as a check-out mechanism is pretty common by package > > managers and other tools. Verifying the tag signature provides > > authentication guarantees, but there is no feedback that the > > signature being verified belongs to the intended tag. > > Very true. > > The above means that the existing package managers and other tools > need to be updated with some new code that lets them learn how to > tell if the tagname (in their refs/tags/ namespace) matches the > intended "real" tag name, and your --check-name option could be > that. > > But if you are adding new code to the existing package managers and > other tools _anyway_, wouldn't it be a more direct solution to let > them learn how to tell what the intended "real" tag name is with > that new code? Yeah, you're right, I didn't consider that. I'm thinking that this kind of verification could simplify the lives of upstream maintainers if we do the verification in-house though (i.e., by having them just add the flag). > > which may be cumbersome. Perhaps, just like "git tag -v v1.4.11" is > a way to see if the contents of the tag is signed properly, if you > add "git tag --show-tagname v1.4.11" that does the above pipeline, > these package managers and other tools can be updated to > ... > make dest=/usr/local/$package/$tag install > > i.e. ignore the refname entirely and use the "real" tagname it reads > after validating the signature as the name of the resulting version > getting installed, distributed and/or used. This is also an alternative, that might be cleaner. I'm wondering if this is easier to implement than having the --check-name flag. Intuitively, it seems like that's the case. Would you suggest taking this path instead? Thanks! -Santiago. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html