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