On 07/03/2017 11:19 PM, Allan McRae wrote:
This should be fixed in git.
Not that I disagree, but it appears this potential attack was discovered a year ago, and sangy has in the meantime (since I started writing this patch and before I emailed it and then noticed his link) posted a link on IRC to the upstream discussion on fixing this in git(1). http://public-inbox.org/git/20161007210721.20437-1-santiago@nyu.edu/ It would appear that upstream believes the fix is by adding git porcelain/plumbing around the process of determining $tagname (rather than relying on git-cat-file(1) piped to awk) and allowing git itself to consider such tags as valid refs in the git repository. Or, actually, I am not sure when this was added or what that patchset accomplished, because it appeared to target `git tag -v` and `git verify-tag`... by completely deleting everything but the now-valid --format value, while presumably `git tag -l` which always accepted --format continued to do what it always did? What I do know is that the current version of git accepts --format='%tag' everywhere relevant, and checking for this kind of modification can and apparently should be done by every single project or human interface that wants to make sure it isn't a problem. Go figure. So I guess we could use instead: tagname="$(git -C "$dir" tag -l --format='%(tag)' "$fragval")" -- Eli Schwartz