Sebastian Götte [off-list ref] writes:
On 03/26/2013 02:46 AM, Junio C Hamano wrote:> Sebastian Götte [off-list ref] writes:
quoted
quoted
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.
On 03/26/2013 05:26 PM, Junio C Hamano wrote:
Sebastian Götte [off-list ref] writes:
quoted
On 03/26/2013 02:46 AM, Junio C Hamano wrote:> Sebastian Götte [off-list ref] writes:
quoted
quoted
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').