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

[Eric Wong <e@80x24.org>]

Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> 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.