list mirror (unofficial, one of many)
 help / color / Atom feed
From: Colin Walters <>
To: Stefan Beller <>, Santiago Torres <>
Cc: git <>
Subject: Re: upstreaming ?
Date: Mon, 08 Jan 2018 21:30:51 -0500
Message-ID: <> (raw)
In-Reply-To: <>

On Mon, Jan 8, 2018, at 3:49 PM, Stefan Beller wrote:
> On Mon, Jan 8, 2018 at 12:40 PM, Santiago Torres <> wrote:
> > Hi,
> >
> > I personally like the idea of git-evtags, but I feel that they could be
> > made so that push certificates (and being hash-algorithm agnostic)
> > should provide the same functionality with less code.
> >
> > To me, a git evtag is basically a signed tag + a data structure similar
> > to a push certificate embedded in it. I wonder if, with the current
> > tooling in git, this could be done as a custom command...
> In that case, why not migrate Git to a new hash function instead
> of adding a very niche fixup?

Every day, for many years I find it maddening and really ridiculous
that the Fedora package build process insists I provide it a tarball
instead of being able to just fetch a signed git tag.

Now while I haven't fought the battle to teach Fedora to actually use
this, I think I have a pretty strong argument that git-evtag very clearly
fulfills the same role that a signed tarball does.

In particular, how a single checksum covers the entire source - no
hash tree involved.  The way that the evtag is "horizontal" across
the source while the git tree is "vertical" around history means
they're complementary.
> See Documentation/technical/hash-function-transition.txt
> for how to do it.

evtag took me a day or two to write initially and doesn't
impose any requirements on users except a small additional
bit of software.

In contrast, working on hash-function-transition.txt?  That
seems like it'd easily consume many person-months of work.
And that plan only exists, whereas git-evtag
long predates both.

> Personally I'd dislike to include ev-tags as it might send a signal
> of "papering over sha1 issues instead of fixing it".

I don't agree.  I think it's pretty clear that a hash function transition
would be a huge amount of work - not least because of course
there are now at least two widely used implementations of git in C,
plus plus...

> push certificates are somewhat underdocumented, see the

Why not call them "git signed pushes"?  Junio's post
even says "the signed push".

And I just looked at this a little bit more but I'm not sure I
see how this covers the same goal as evtags; it seems
more about stopping someone from MITM my push
to, and not about ensuring integrity from
someone pulling from (and not wanting
to fully trust github).

  parent reply index

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-01-08 20:12 Colin Walters
2018-01-08 20:34 ` Johannes Schindelin
2018-01-08 20:40 ` Santiago Torres
2018-01-08 20:42   ` Colin Walters
2018-01-08 20:51     ` Santiago Torres
2018-01-08 20:49   ` Stefan Beller
2018-01-08 20:54     ` Santiago Torres
2018-01-09  2:30     ` Colin Walters [this message]
2018-01-09 18:09       ` Santiago Torres
2018-01-09 20:38         ` Jonathan Nieder
2018-01-10 16:38           ` Santiago Torres

Reply instructions:

You may reply publically 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:

  List information:

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

  git send-email \ \ \ \ \ \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link list mirror (unofficial, one of many)

Archives are clonable:
	git clone --mirror
	git clone --mirror http://ou63pmih66umazou.onion/git
	git clone --mirror http://czquwvybam4bgbro.onion/git
	git clone --mirror http://hjrcffqmbrq6wope.onion/git

Newsgroups are available over NNTP:

 note: .onion URLs require Tor:

AGPL code for this site: git clone public-inbox