On Mon, Jun 04, 2018 at 03:39:26PM +0200, SZEDER Gábor wrote: > On rare occasions the given pattern occurs not only in the commit > message but in the GPG signature as well, and after it's replaced in > the signature the resulting signature becomes invalid, GPG will report > CRC error and that it couldn't find any signature, which will then > ultimately cause the test failure. Ooh, I hadn't seen these failures, but thanks for tracking this down. > Since in all three cases the pattern to be replaced during the forgery > is the first word of the commit message's subject line, and since the > GPG signature in the commit object is indented by a space, let's just > anchor those patterns to the beginning of the line to prevent this > issue. > > The test script 't7030-verify-tag.sh' creates a forged signed tag > object in a similar way by replacing the pattern "seventh", but the > GPG signature in tag objects is not indented by a space, so the above > solution is not applicable in this case. However, in the tag object > in question the pattern "seventh" occurs not only in the tag message > but in the 'tag' header as well. To create a forged tag object it's > sufficient to replace only one of the two occurences, so modify the > sed script to limit the pattern to the 'tag' header (i.e. a line > beginning with "tag ", which, because of the space character, can > never occur in the base64-encoded GPG signature). > > Note that the forgery in 't7004-tag.sh' is not affected by this issue: > while 't7004' does create a forged signed tag kind of the same way, > it replaces "signed-tag" in the tag object, which, because of the '-' > character, can never occur in the base64-encoded GPG signarute. This seems sane and obviously correct, and the other patch looked good, too. Thanks. -- brian m. carlson: Houston, Texas, US OpenPGP: https://keybase.io/bk2204
Attachment:
signature.asc
Description: PGP signature
