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 -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html