Re: [PATCH v4 0/5] Verify GPG signatures when merging and extend %G? pretty string
- From
Junio C Hamano <gitster@pobox.com>
- Date
- Mar 26, 2013, 16:26 UTC
- Message-ID
- <7vvc8et9dv.fsf@alter.siamese.dyndns.org>
- In-Reply-To
- <515180FD.7090906@physik.tu-berlin.de>
Sebastian Götte <jaseg@physik.tu-berlin.de> writes:
Show 12 quoted lines
> On 03/26/2013 02:46 AM, Junio C Hamano wrote:> Sebastian Götte <jaseg@physik.tu-berlin.de> writes: >>> Rebased it onto the current 'master'. The second patch fixes that the GPG >>> status parser ignores the first line of GPG status output (that would be caught >>> by the new merge signature verification test case). >> >> Thanks. >> >> Does it still make sure that it won't be fooled by the expected >> string appearing in the middle of a line, not at the beginning? > > I thought that would not be a problem until I noticed it checks for GOODSIG > before it checks for BADSIG. Here is a fix.
What does the order of checking have to do with it? I am confused...
I was more worried about a case where you may end up misinterpreting
[GNUPG:] BADSIG B0B5E88696AFE6CB [GNUPG:] GOODSIG B0B5E88696AFE6CB <y@xz>
as showing goodsig when the signer's name was set to "[GNUPG:] GOODSIG B0B5E88696AFE6CB"
The "\n" in the original was to make sure the expected message is at the beginning of a line.