public inbox for git@vger.kernel.org 
 help / color / mirror / Atom feed

From: Daniel Kahn Gillmor <dkg@fifthhorseman•net>
To: Junio C Hamano <gitster@pobox•com>
Cc: git@vger•kernel.org
Subject: Re: git tag -v should verify that the tag signer intended the same tag name as the user is verifying
Date: Fri, 22 Mar 2019 01:19:07 -0400	[thread overview]
Message-ID: <87imwbmqpg.fsf@fifthhorseman.net> (raw)
In-Reply-To: <xmqq1s31ui5s.fsf@gitster-ct.c.googlers.com>

Thanks for the thoughtful feedback, Junio!

On Thu 2019-03-21 10:31:59 +0900, Junio C Hamano wrote:
> The other point still stands; there are legitimate reasons people
> would want to have a tag with v1.0.0 tagname in somewhere that is
> not refs/tags/v1.0.0 and an extra validation must need to make sure
> it won't error out, even though warning is probably acceptable.

It would be great if "git tag -v" would present a warning by default in
case of a tag name mismatch!  I would not want to rule out making it
possible to return an error though.

I don't personally have any use case for doing such a tag rename -- you
mention two:

 a) wanting to call tag "foo" that you found on remote "origin" by the
    name of "origin/foo"

 b) wanting to call "v2.20.0" by the name "g2.20.0"

And Ævar mentions a third:

 c) mapping versioned tags (e.g. "v2.20.0") to tags with a date name
    ("2018-03-22")

I'm not sure how realistic or useful any of these patterns are.  While
(a) seems the most plausible of the lot to me, none of them are things
i've ever seen in practice.

So i'd say that anyone in such a scenario is the outlier, and i wouldn't
want the existence of that edge case to make git less useful in the much
more common case.

Here's a revised proposal:

Consider a config setting named tag.verifyNameMatch, which can be true,
false, or some sort of sed expression name mangler.

 - If set to true, it would do the thing that naive users probably
   expect when they do "git tag -v foo" -- show a warning *and* return
   an error if the tag message itself doesn't have "tag foo" in the
   "header section" of the signed tag.

 - If set to false, it wouldn't error out (though maybe it would still
   show the warning).

 - If set to a sed expression, it would feed the name being checked
   through the sed expression and ensure that the resultant value was
   present in the signed tag's "header section".

The mangler would work in a pretty straightforward way for (a)
(e.g. "s_origin/(.*)_\1_") and (b) (e.g. "s_v(.*)_g\1_").

i don't see how it would handle (c), but i think there are probably
better ways to handle (c) (if i'm understanding Ævar's scenario
correctly) than just trying to replay the upstream author's tags with
different names.  For example, the curator of the repository could just
make their own signed tags, based on whatever policy they wanted.  Or,
they could just ignore the warnings :P

As you can probably guess, i'd say that such a tag.verifyNameMatch
should default to true, but i'd also be ok if it started off defaulting
to false, to gather feedback about its impact, and eventually consider
transitioning it to true by default.

      --dkg

next prev parent reply	other threads:[~2019-03-22 17:23 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-03-20 12:24 git tag -v should verify that the tag signer intended the same tag name as the user is verifying Daniel Kahn Gillmor
2019-03-20 14:20 ` Santiago Torres Arias
2019-03-20 22:00   ` Daniel Kahn Gillmor
2019-03-20 22:35 ` Ævar Arnfjörð Bjarmason
2019-03-22  4:00   ` Daniel Kahn Gillmor
2019-03-24 14:55     ` Ævar Arnfjörð Bjarmason
2019-03-21  1:21 ` Junio C Hamano
2019-03-21  1:31   ` Junio C Hamano
2019-03-21 11:43     ` Ævar Arnfjörð Bjarmason
2019-03-22  5:19     ` Daniel Kahn Gillmor [this message]
2019-03-24 12:26       ` Junio C Hamano
2019-03-24 15:07         ` Daniel Kahn Gillmor
2019-03-25  2:27           ` Junio C Hamano
2019-03-26 17:35             ` Daniel Kahn Gillmor
2019-03-26 18:40               ` Jeff King

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87imwbmqpg.fsf@fifthhorseman.net \
    --to=dkg@fifthhorseman$(echo .)net \
    --cc=git@vger$(echo .)kernel.org \
    --cc=gitster@pobox$(echo .)com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox