Thread (1 message) 1 message, 1 author, 2016-08-26

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

From: Johannes Schindelin <hidden>
Date: 2016-08-26 08:08:59

Hi Arif,

On Thu, 25 Aug 2016, Arif Khokar wrote:
On 08/25/2016 09:01 AM, Johannes Schindelin wrote:
quoted
On Thu, 25 Aug 2016, Arif Khokar wrote:
quoted
quoted
quoted
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
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help