On 03/26/2013 05:26 PM, Junio C Hamano wrote:
Sebastian Götte ja...@physik.tu-berlin.de writes:
On 03/26/2013 02:46 AM, Junio C Hamano wrote: Sebastian Götte
ja...@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.
I was assuming only a malicious user would use a name containing [GNUPG:]
SOMETHING_ALLCAPS. In this case, if the code would check for
BADSIG/TRUST_NEVER/TRUST_UNKNOWN messages first, the signature would still be
rejected. Of course, in that case a non-malicious user with a name containing
[GNUPG:] BADSIG etc. would still run into problems.
This 4th version fixes that by checking whether the search string is at the
beginning of the status buffer (index 0) or at the beginning of a line
(prefixed by '\n').
--
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
