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

[Johannes Schindelin <Johannes.Schindelin@gmx.de>]

Hi Arif,

On Thu, 25 Aug 2016, Arif Khokar wrote:

> On 08/25/2016 09:01 AM, Johannes Schindelin wrote:
> >
> > On Thu, 25 Aug 2016, Arif Khokar wrote:
> 
> >>> 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.
> >>
> >> It should be possible to verify the SHA1 of the blob before and after
> >> the patch is applied given the values listed near the beginning of
> >> the git diff output.
> >
> > There is no guarantee that the SHA-1 has not been tampered with.
> 
> I was implying that the resulting SHA1 of the blob after the malicious
> patch was applied would differ compared to the resulting blob after
> applying the innocuous patch.  Even if you alter the SHA1 value within
> the patch itself, it doesn't change the SHA1 of the result (unless
> you're able to get a hash collision).
> 
> But, if you want to guarantee that the SHA1 hasn't been tampered in the
> email, you could sign it with your private GPG key and others could
> verify the signature with your public key (assuming the web-of-trust
> applies).

Given that I try to convince my fellow core Git developers to adopt an
*easier* patch submission process, that wastes less of contributors' time,
I would be strongly opposed to requiring a web of trust and GPG signatures
just to be able to submit patches to git.git.

Ciao,
Johannes