On Thu, Apr 22, 2021 at 1:54 AM Ævar Arnfjörð Bjarmason <avarab@xxxxxxxxx> wrote: > > On Wed, Apr 21 2021, Elijah Newren wrote: > > > On Wed, Apr 21, 2021 at 11:54 AM Junio C Hamano <gitster@xxxxxxxxx> wrote: > >> > >> Elijah Newren <newren@xxxxxxxxx> writes: > >> > >> > On Tue, Apr 20, 2021 at 2:40 PM Junio C Hamano <gitster@xxxxxxxxx> wrote: > >> >> ... > >> >> +The `<refname>` is prefixed with `refs/tags/` when stored > >> >> in Git, so importing the CVS branch symbol `RELENG-1_0-FINAL` would > >> >> -use just `RELENG-1_0-FINAL` for `<name>`, and fast-import will write the > >> >> +use just `RELENG-1_0-FINAL` for `<refname>`, and fast-import will write the > >> >> corresponding ref as `refs/tags/RELENG-1_0-FINAL`. > >> > > >> > Going on a slight tangent since you didn't introduce this, but since > >> > you're modifying this exact documentation... > >> > > >> > I hate the assumed "refs/tags/" prefix. Especially since ... > >> > ... The special casing reminds me of the ref-updated hook in > >> > gerrit > >> > >> Gerrit and fast-import? What is common is Shawn, perhaps ;-)? > > > > :-) To be fair, though, given the number of things he created for us, > > it's inevitable there'd be a few small things causing problems and > > these are small potatoes in the big scheme of things. ref-updated was > > fixed years ago, and it sounds like Luke is about to fix the tag > > prefix assumption for us. > > > >> > broken given the fact that the name inside the tag didn't match the > >> > name of the actual ref. (To be honest, though, I was never sure why > >> > the name of the tag was recorded inside the tag itself.) > >> > >> The name of the tag and the name of the object has to be together > >> for a signature over it to have any meaning, no? > > > > Oh, I guess if you treat the signature as affirming that not only do > > you like the object but that it has a particular nickname, then yes > > you'd need both. I had always viewed a signed tag as an affirmation > > that the object was good/tested/verified/whatever, and viewed the > > nickname of that good object as ancillary. I have to admit to not > > using signed tags much, though. > > The current behavior leaves the door open to an attack where say git has > a security point-release v2.31.2, and you have my hostile repo as a > remote, and I've sneakily replaced v2.31.2 in that repo with the object > pointed-to by v2.31.1. > > You "update" (but not really), verify v2.31.2 with Junio's GPG key, > which is all correctly signed content. But the tag name isn't what you > expected, and thus you don't get the security fix, I use this > information to attack you. > > This already unplausible but hypothetical attack was sort-of-maybe > plausible before my 0bc8d71b99e (fetch: stop clobbering existing tags > without --force, 2018-08-31). > > That was released with v2.20.0, before that I could more easily sneak > such a tag into your repo knowing that you were doing a "git fetch > --all" and had my evil git.git clone[1] on github.com evil remote. Now > that's unlikely to happen, in practice the "fetch --all" happens in > order, you'll have your "origin" remote first in the file (it's the way > git config adds them), and will get the good tag first. > > Hrm, I suppose with --jobs and a race condition that might not always be > true. Aside from this mostly imaginary issue maybe having --jobs be > deterministic (i.e. "fetch content in parallel, apply ref updates in > sequence") might be a good idea.. Ah, interesting. Thanks for the explanation. > Anyway, getting back on point since no release of git has cared about > the "tag" field I'd be inclined to say that we should explicitly > document that we don't care, and perhaps document this caveat. > > 1. Disclosure: I know of no actual evilness except a bunch of crappy WIP > code in my git.git fork on github.
