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

From: Daniel Kahn Gillmor <dkg@fifthhorseman•net>
To: Santiago Torres Arias <santiago@nyu•edu>
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: Wed, 20 Mar 2019 18:00:11 -0400	[thread overview]
Message-ID: <87bm25rytw.fsf@fifthhorseman.net> (raw)
In-Reply-To: <20190320142055.zlh5iby5pxs3fy3r@LykOS.localdomain>

[-- Attachment #1: Type: text/plain, Size: 2649 bytes --]

Hi Santiago--

On Wed 2019-03-20 10:20:57 -0400, Santiago Torres Arias wrote:
> This has been known for a whlie now[1]. The consensus back then was that
> this information was up to higher-level integrators to verify using
> means like e.g., --format.
>
> [1] https://public-inbox.org/git/xmqqk2hzldx8.fsf@gitster.mtv.corp.google.com/

Thanks for this pointer to the history!  Glad to see people have pushed
on it in the past, even if i don't think the place that conversation
wound down to is the right place to settle.

> This is implemented in for example pacman/devtools here[2].
>
> [2] https://lists.archlinux.org/pipermail/pacman-dev/2017-September/022123.html

Sigh.  This is exactly the kind of redundant implementation situation
that i'm afraid of getting into.  as the comment in that patch says:

    This really should be fixed in git itself, rather than forcing all
    downstream users of git verify-tag to implement their own checks,

Git gets to decide what choices to make here about what the default
verification process is, and the default verification step should be
sensible and narrowly aligned to the standard case associated with
revision control tag verification.

gpg and gpgv can both be used to confirm the validity of the signature,
but those tools don't (and architecturally can't) know that they're
being used in the context of git -- so it's important that git supplies
that domain-specific knowledge to the verification step.

fwiw, i'm pushing for comparable checks in the git-buildpackage

   https://bugs.debian.org/925118

but it seems pretty silly (and likely error-prone) to have to rewrite
the same check in every tool that uses "git tag -v".

> We published a paper with a more thorough security model here[3], and
> there's some stalled work into implementing this using push
> certificates...
>
> [3] https://www.usenix.org/conference/usenixsecurity16/technical-sessions/presentation/torres-arias

I'm not convinced that push certificates solves this problem, if i'm
understanding the work right.  push certificates have to do specifically
with the ability to push to a repository, but here we're talking about
arbitrary verifiers who have passive (read-only) access to a repository
wanting to verify a given tag.

If you're talking about using a push certificate as a substitute for a
signed tag itself, then that sounds like we're giving up on signed tags
meaning what everyone expects them to mean, all because we can't get the
verification process to work right.  That doesn't seem like a good
outcome.

Thanks for talking through this -- hopefully we can figure out a good
way forward.

       --dkg

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 227 bytes --]

next prev parent reply	other threads:[~2019-03-20 22:00 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 [this message]
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
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=87bm25rytw.fsf@fifthhorseman.net \
    --to=dkg@fifthhorseman$(echo .)net \
    --cc=git@vger$(echo .)kernel.org \
    --cc=santiago@nyu$(echo .)edu \
    /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