From: Colin Walters <firstname.lastname@example.org> To: Stefan Beller <email@example.com>, Santiago Torres <firstname.lastname@example.org> Cc: git <email@example.com> Subject: Re: upstreaming https://github.com/cgwalters/git-evtag ? Date: Mon, 08 Jan 2018 21:30:51 -0500 Message-ID: <1515465051.2895186.1228754952.0036D645@webmail.messagingengine.com> (raw) In-Reply-To: <CAGZ79kZ8AXezcX1_5WJsUJMHiHCzj2B=Uj8+4K3VF+cC6mTCqA@mail.gmail.com> On Mon, Jan 8, 2018, at 3:49 PM, Stefan Beller wrote: > On Mon, Jan 8, 2018 at 12:40 PM, Santiago Torres <firstname.lastname@example.org> 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 post-shatter.io, 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 https://www.eclipse.org/jgit/ 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 github.com, and not about ensuring integrity from someone pulling from github.com (and not wanting to fully trust github).
next prev 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: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style List information: http://vger.kernel.org/majordomo-info.html * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=1515465051.2895186.1228754952.0036D645@webmail.messagingengine.com \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ /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
email@example.com mailing list mirror (one of many) Archives are clonable: git clone --mirror https://public-inbox.org/git 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: nntp://news.public-inbox.org/inbox.comp.version-control.git nntp://ou63pmih66umazou.onion/inbox.comp.version-control.git nntp://czquwvybam4bgbro.onion/inbox.comp.version-control.git nntp://hjrcffqmbrq6wope.onion/inbox.comp.version-control.git nntp://news.gmane.org/gmane.comp.version-control.git note: .onion URLs require Tor: https://www.torproject.org/ or Tor2web: https://www.tor2web.org/ AGPL code for this site: git clone https://public-inbox.org/ public-inbox