Re: Working with public-inbox.org [Was: [PATCH] rev-parse: respect core.hooksPath in --git-path]

From: Eric Wong <e@80x24.org>
Date: Aug 24, 2016, 19:16 UTC
Message-ID: <20160824191651.GC8578@whir>
In-Reply-To: <alpine.DEB.2.20.1608241459360.4924@virtualbox>

Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:

Show 15 quoted lines

> On Mon, 22 Aug 2016, Philip Oakley wrote:
> > I do note that dscho's patches now have the extra footer (below the three
> > dashes) e.g.
> > 
> > Published-As: https://github.com/dscho/git/releases/tag/cat-file-filters-v1
> > Fetch-It-Via: git fetch https://github.com/dscho/git cat-file-filters-v1
> > 
> > If say I used that, and sent my patch series via Outlook Express (<sigh>),
> > with it's white space damage, would those footers help once the content has
> > been reviewed (rather than white spacing style) in the applying the patch?
> 
> I considered recommending this as some way to improve the review process.
> The problem, of course, is that it is very easy to craft an email with an
> innocuous patch and then push some malicious patch to the linked
> repository.

Perhaps an automated checker of some sort packaged with git would help. (And perhaps combinable with the downloader Arif proposed)

> Now, with somebody like me who would lose a lot when destroying trust, it
> is highly unlikely. But it is possible that in between the hundreds of
> sincere contributors a bad apple tries to sneak in bad stuff.

Yes, I would never mix reviews + patch applications of emails vs git-fetched data. Having a sender providing both is good; but the recipient needs to pick one or the other to use exclusively for that series.

Either look exclusively at what is fetched and respond to that; or look exclusively at emails and ignore data from git fetch.

However, ensuring the emails and the contents of the git fetch could be done optionally to ensure there's no tampering or accidents for other reviewers.

> Therefore, if we were to support a Git-driven contribution process that
> *also* sends mail, that mail needs to be generated by a trusted source, to
> ensure that the content of the mail is identical to the original Git
> commits.

For decentralized systems, independent reproducibilility is needed. Rather than trusting one source, I'd rather have some sort of downloading + checking tool which checks multiple mirrors (git protocols and NNTP). That would allow users to independently verify the veracity of what they got emailed vs what is fetched.