On 03/26/2013 05:26 PM, Junio C Hamano wrote: > Sebastian Götte <jaseg@xxxxxxxxxxxxxxxxxxx> writes: > >> On 03/26/2013 02:46 AM, Junio C Hamano wrote:> Sebastian Götte <jaseg@xxxxxxxxxxxxxxxxxxx> 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 majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html