From: Michael J Gruber <git@drmicha•warpmail.net>
To: Jeff King <peff@peff•net>, Santiago Torres <santiago@nyu•edu>
Cc: Git <git@vger•kernel.org>
Subject: Re: [RFC] tag-ref and tag object binding
Date: Wed, 27 Jan 2016 08:23:02 +0100 [thread overview]
Message-ID: <56A87056.2010309@drmicha.warpmail.net> (raw)
In-Reply-To: <20160126202651.GA1090@sigill.intra.peff.net>
Jeff King venit, vidit, dixit 26.01.2016 21:26:
> On Tue, Jan 26, 2016 at 10:29:42AM -0500, Santiago Torres wrote:
>
>>> If you cannot trust those with write access to a repo that you are
>>> pulling and installing from you might want to re-check where you are
>>> pulling or installing from ;)
>>
>> Yeah, I see your point, but mechanisms to ensure the server's origin can
>> be bypassed (e.g., a MITM). I don't think it would hurt to ensure the
>> source pointed to is the source itself. The tag signature can help us do
>> this.
>
> Right. I think the more interesting use case here is "I trust the
> upstream repository owner, but I do not trust their hosting site of
> choice."
>
>>> Your best bet is checking the signature of signed tags. Now, if you're
>>> worried about someone maliciously pointing you to the wrong, correctly
>>> signed tag then you should verify that the tag object contains the tag
>>> "name" that you expect (for example by using "git verify-tag -v" or "git
>>> cat-file -p"), since that is part of the signed content.
>>
>> Yep, this is my intuition behind my proposal. While someone can manually
>> inspect a tag (git tag -v [ref]) to ensure he's getting the correct one,
>> there's no mechanism to ensure that the ref is pointing to the intended
>> tag. I do believe that package managers and git submodules could check
>> whether the ref is pointing to the right tag with a small change in the
>> tag header. Although it would be up to each tool to implement this
>> check.
>>
>> I don't think that an addition like this would get in the way of any
>> existing git workflow, and should be backwards-compatible right?
>
> Doesn't this already exist?
>
> $ git cat-file tag v2.0.0
> object e156455ea49124c140a67623f22a393db62d5d98
> type commit
> tag v2.0.0
> tagger Junio C Hamano <gitster@pobox•com> 1401300269 -0700
>
> Git 2.0
> -----BEGIN PGP SIGNATURE-----
> [...]
> -----END PGP SIGNATURE-----
>
> Tag objects already have a "tag" header, which is part of the signed
> content. If you use "git verify-tag -v", you can check both that the
> signature is valid and that the tag is the one you are expecting.
Yes, that's what I described in my last paragraph, using the term
(embedded) tag "name" which is technically wrong (it's not the tag
object's name, which would be a sha1) but the natural term for users.
> Of course, "verify-tag" could do this for you if you give it a refname,
> too, but I think that may be the tip of the iceberg in terms of
> automatic verification. In particular, verify-tag knows it was signed by
> _somebody_, but it doesn't know what the signing policy is. As a human,
> _I_ know that Junio is the right person to be signing the release tag,
> but no tool does.
>
> Git pretty much punts on all of these issues and assumes either a human
> or a smarter tool is looking at the verification output. But I don't
> think it would hurt to build in some features to let git automatically
> check some things, if only to avoid callers duplicating work to
> implement the checks themselves.
That is really a can of worms for several reasons:
- Do you fetch tags into refs/tags/ or refs/tags/upstream/ or wherever,
and which part of the tag refname should we check for?
We can DWIM that to the last part after / and allow "--tagname" to
override, of course.
- By all means, we need to avoid a false sense of security. "GOOD
SIGNATURE" in gpg terms is bad enough with the usual trust model when
users don't check who actually made that signature.
If you don't *really* check the signature then anyone can shove a signed
tag object under your nose with the *expected tag header* (tag "name")
so that there is no gain at all, unless you envison a scenario where Man
I. T. Middle can mess with refs but not objects.
So, for those who shy away from for-each-ref and such, we may add the
header check to verify-tag, with a big warning about the marginal gain
in security (or the requirements for an actual gain).
Michael
next prev parent reply other threads:[~2016-01-27 7:23 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-01-25 21:22 [RFC] tag-ref and tag object binding Santiago Torres
2016-01-26 9:35 ` Michael J Gruber
2016-01-26 15:29 ` Santiago Torres
2016-01-26 20:26 ` Jeff King
2016-01-26 21:13 ` Junio C Hamano
2016-01-28 21:09 ` Santiago Torres
2016-01-26 21:44 ` Santiago Torres
2016-01-26 22:44 ` Junio C Hamano
2016-01-27 7:23 ` Michael J Gruber [this message]
2016-01-27 7:33 ` Jeff King
2016-01-27 7:53 ` Michael J Gruber
2016-01-27 8:09 ` Jeff King
2016-01-27 9:14 ` Michael J Gruber
2016-01-27 18:10 ` Junio C Hamano
2016-01-27 20:09 ` Michael J Gruber
2016-01-27 20:21 ` Jeff King
2016-01-28 21:06 ` Santiago Torres
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=56A87056.2010309@drmicha.warpmail.net \
--to=git@drmicha$(echo .)warpmail.net \
--cc=git@vger$(echo .)kernel.org \
--cc=peff@peff$(echo .)net \
--cc=santiago@nyu$(echo .)edu \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox