Re: upstreaming https://github.com/cgwalters/git-evtag ?

[Colin Walters]

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 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).

Re: upstreaming https://github.com/cgwalters/git-evtag ?

[Colin Walters]

On Mon, Jan 8, 2018, at 3: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.

What's a "push certificate"?  (I really tried to find it in Google,
even going to page 4 where one can start to see tumbleweeds
going by... I'm fairly certain you're not talking about something related
to iOS notifications) 

upstreaming https://github.com/cgwalters/git-evtag ?

[Colin Walters]

Hi, so quite a while ago I wrote this:
https://github.com/cgwalters/git-evtag

Since I last posted about this on the list here, of course
shattered.io happened.  It also looks
like there was a node.js implementation written.

Any interest in having this in core git?  

git-evtag v2016.1

[Colin Walters]

A while ago, I started a discussion on stronger verification of git
tags:

http://permalink.gmane.org/gmane.comp.version-control.git/264533

Since then I've been maintaining:
https://github.com/cgwalters/git-evtag

Which I think works well.  At some point I'd like to discuss merging
some of the functionality into the git core.  

However it's been useful to have a standalone program so that
I don't have to wait until a new version of git comes out, and it's
also just easier to prototype.

For those interested, a new version of git-evtag is available:

https://github.com/cgwalters/git-evtag/releases/tag/v2016.1

--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: weaning distributions off tarballs: extended verification of git tags

[Colin Walters]

On Sat, Feb 28, 2015, at 10:48 AM, Colin Walters wrote:
 Hi, 
 
 TL;DR: Let's define a standard for embedding stronger checksums in tags and 
 commit messages:
 https://github.com/cgwalters/homegit/blob/master/bin/git-evtag

[time passes]

I finally had a bit of time to pick this back up again in:

https://github.com/cgwalters/git-evtag

It should address the core concern here about stability of `git archive`.

I prototyped it out with libgit2 because it was easier, and I'd like actually 
to be able to use this with older versions of git.

But I think the next steps here are:

- Validate the core design
  * Tree walking order
  * Submodule recursion
  * Use of SHA512
- Standardize it
  (Would like to see at least a stupid slow shell script implementation to 
cross-validate)
- Add it as an option to `git tag`?

Longer term:
- Support adding `Git-EVTag` as a git note, so I can retroactively add stronger
  checksums to older git repositories
- Anything else?

--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: weaning distributions off tarballs: extended verification of git tags

[Colin Walters]

On Sat, Feb 28, 2015, at 03:34 PM, Morten Welinder wrote:
 Is there a point to including a different checksum inside
 a git tag?  If someone can break the SHA-1 checksum
 in the repository then the recorded SHA-256 checksum can
 be changed.  In other words, wouldn't you be just as well
 off handing someone a SHA-1 commit id?

The issue is more about what the checksum covers, as
well as its strength.  Git uses a hash tree, which means
that an attacker only has to find a collision for *one* of
the objects, and the signature is still valid.  And that collision
is valid for *every* commit that contains that object.

This topic has been covered elsewhere pretty extensively,
here's a link:
https://www.whonix.org/forum/index.php/topic,538.msg4278.html#msg4278

Now I think rough consensus is still that git is secure or
secure enough - but with this proposal I'm just trying
to overcome the remaining conservatism.  (Also, while those
discussions were focusing on corrupting an existing repository,
the attack model of MITM also exists, and there
you don't have to worry about deltas, particularly if the
attacker's goal is to get a downstream to do a build
and thus execute their hostile code inside the downstream
network).

It's really not that expensive to do once per release,
basically free for small repositories, and for a large one like
the Linux kernel:

$ cd ~/src/linux
$ git describe
v3.19-7478-g796e1c5
$ time /bin/sh -c 'git archive --format=tar HEAD|sha256sum'
4a5c5826cea188abd52fa50c663d17ebe1dfe531109fed4ddbd765a856f1966e  -

real0m3.772s
user0m6.132s
sys 0m0.279s
$

With this proposal, the checksum
covers an entire stream of objects for a given commit at once;
making it significantly harder to find a collision.  At least as good as 
checksummed tarballs, and arguably better since it's
pre-compression.

So to implement this, perhaps something like:

$ git archive --format=raw

as a base primitive, and:

$ git tag --archive-raw-checksum=SHA256 -s -m ...

?

git fsck could also learn to optionally use this.
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

weaning distributions off tarballs: extended verification of git tags

[Colin Walters]

Hi, 

TL;DR: Let's define a standard for embedding stronger checksums in tags and 
commit messages:
https://github.com/cgwalters/homegit/blob/master/bin/git-evtag

I think tarballs should go away as a source distribution mechanism in favor of 
pure git.  I won't go into too many details of the why here (hopefully most 
of you agree!) but that's the background.

Now, there are a few things that the classical tarball model provides:

- Version numbers compatible with dpkg/rpm/etc
  - Do the same with your tag names, and use a well known scheme like 
v$VERSION
- The assumption that this source has been run through some tests
  - Broken assumption, and regardless you want to rerun tests downstream
- Hosting providers typically offer a strong checksum over the entire source
  - The topic of this post

The above strawman code allows embedding the SHA256(git archive | tar).  Now,
in order to make this work, the byte output of git archive must never change 
in the
future.  I'm not sure how valid an assumption this is.  Timestamps are set to 
the
commit timestamp, but I could imagine someone wanting to come along later
and tweak the output to be compatible with some variant of tar or something.

We could define the checksum to be over the stream of raw objects, sorted by 
their checksum,
and that way be independent of archiving format variations.

Is there agreement that something like this makes sense in the git core?  Does 
the
concept make sense?  Does anything like this exist today?  Other 
thoughts/objections?
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html