From: "Ævar Arnfjörð Bjarmason" <avarab@gmail.com>
To: Junio C Hamano <gitster@pobox.com>
Cc: Daniel Kahn Gillmor <dkg@fifthhorseman.net>, 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: Thu, 21 Mar 2019 12:43:13 +0100 [thread overview]
Message-ID: <87r2b0cv1q.fsf@evledraar.gmail.com> (raw)
In-Reply-To: <xmqq1s31ui5s.fsf@gitster-ct.c.googlers.com>
On Thu, Mar 21 2019, Junio C Hamano wrote:
> Junio C Hamano <gitster@pobox.com> writes:
>
>> * "git tag -v $(git rev-parse v1.0.0)" should work, but the command
>
> Sorry, forget about this part of my message. I completely forgot the
> discussion we had a few years ago:
>
> https://public-inbox.org/git/CAPc5daV9ZvHqFtdzr565vp6Mv7O66ySr-p5Vi8o6bd6=GyVELg@mail.gmail.com/
>
> In short, "git tag -v TAGNAME" does not take an arbitrary object
> name, TAGNAME does not go through the usual ref dwimming rules
> (i.e. checking for .git/%s, .git/tag/%s, .git/heads/%s, ... to find
> one) but only looks at refs/tags/TAGNAME alone. So we always have
> the refname it came from when inspecting tag contents that tells
> what tagname the tag has.
>
> 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.
One such example, which I don't know is actually used, but we might be
careful to break is:
* Someone (e.g. Junio) is producing signed tags of a project like
git.git
* Someone else has a git repo where only upstream (signed by Junio)
releases are allowed, but they decide *which* release.
* Some system auto-deploys whatever the latest sorted tag in that repo
is, after verifying that Junio tagged them.
Thus e.g. v2.21.0 might be pushed as refs/tags/2018-03-21, and if it
doesn't work out a new refs/tags/2018-03-22 might be tagged tomorrow
using the v2.20.0 tag.
next prev parent reply other threads:[~2019-03-21 11:43 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 [this message]
2019-03-22 5:19 ` Daniel Kahn Gillmor
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=87r2b0cv1q.fsf@evledraar.gmail.com \
--to=avarab@gmail.com \
--cc=dkg@fifthhorseman.net \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.