All of lore.kernel.org
 help / color / mirror / Atom feed
From: Michael J Gruber <git@drmicha.warpmail.net>
To: Jeff King <peff@peff.net>
Cc: git@vger.kernel.org, ZhenTian <loooseleaves@gmail.com>
Subject: Re: [PATCH] gpg-interface: check gpg signature for correct header
Date: Tue, 14 Jun 2016 13:34:20 +0200	[thread overview]
Message-ID: <3ccf7649-be0e-dcb8-c9a7-cdc36dc85d16@drmicha.warpmail.net> (raw)
In-Reply-To: <20160614112006.GA15889@sigill.intra.peff.net>

Jeff King venit, vidit, dixit 14.06.2016 13:20:
> On Tue, Jun 14, 2016 at 01:11:19PM +0200, Michael J Gruber wrote:
> 
>> When we create a signature, it may happen that gpg returns with
>> "success" but not with an actual detached signature on stdout.
>>
>> Check for the correct header to catch these cases better.
> 
> Seems like a reasonable idea.
> 
> I do worry that checking for PGP_SIGNATURE is a little fragile, though.
> We currently let you sign with gpgsm, for example, and I think this
> would break it (the verification side is not great because we don't
> recognize gpgsm headers, but this feels like a step backwards).
> 
> That wouldn't be too hard to work around with a "is this a signature"
> function that checks both types.
> 
>> diff --git a/gpg-interface.c b/gpg-interface.c
>> index c4b1e8c..664796f 100644
>> --- a/gpg-interface.c
>> +++ b/gpg-interface.c
>> @@ -185,7 +185,7 @@ int sign_buffer(struct strbuf *buffer, struct strbuf *signature, const char *sig
>>  
>>  	sigchain_pop(SIGPIPE);
>>  
>> -	if (finish_command(&gpg) || !len || len < 0)
>> +	if (finish_command(&gpg) || !len || len < 0 || strncmp(signature->buf, PGP_SIGNATURE, strlen(PGP_SIGNATURE)))
>>  		return error(_("gpg failed to sign the data"));
> 
> I think your strncmp is better spelled:
> 
>   starts_with(signature->buf, PGP_SIGNATURE);
> 
> The check for "!len" is redundant now. I think you could drop "len < 0"
> as well (and in fact, drop the "len" variable entirely), as in the error
> case we'd simply have an empty signature->len.
> 
> Your patch effectively swaps out "did we get any data" for "did we get
> the data we expect", which is what those "len" checks were doing.
> 
> -Peff
> 

My patch actually makes several tests fail, sorry. (I did check before
that I can still create signatures...) Maybe my offset in buf is wrong.

starts_with, yes.

Can't check any further now, sorry. But we do check for the
PGP_SIGNATURE in our signed objects anyways. So I feel that we can either

- tighthen the check for valid gpg signatures

or

- make our signature interface completely pluggable.

We can't have it both ways, but at least things are localised in
gpg-interface.c now.

The proposed patch is just some consistency check that does not rely on
gpg.program itself(!), or else we could simply call verify.

Michael

  reply	other threads:[~2016-06-14 11:34 UTC|newest]

Thread overview: 31+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-06-14  7:50 I lost my commit signature ZhenTian
2016-06-14  7:58 ` Jeff King
2016-06-14  8:09   ` ZhenTian
2016-06-14  8:18     ` Jeff King
2016-06-14  8:39       ` ZhenTian
2016-06-14  9:41         ` Jeff King
2016-06-14  9:56           ` ZhenTian
2016-06-14 10:57           ` Michael J Gruber
2016-06-14 11:11             ` [PATCH] gpg-interface: check gpg signature for correct header Michael J Gruber
2016-06-14 11:20               ` Jeff King
2016-06-14 11:34                 ` Michael J Gruber [this message]
2016-06-14 11:58                   ` Michael J Gruber
2016-06-14 12:05                     ` [PATCHv2] " Michael J Gruber
2016-06-14 14:44                     ` [PATCHv3] gpg-interface: check gpg signature creation status Michael J Gruber
2016-06-14 18:13                       ` Junio C Hamano
2016-06-14 21:50                         ` Jeff King
2016-06-14 22:26                           ` Jeff King
2016-06-14 23:47                             ` Junio C Hamano
2016-06-15  0:56                               ` Jeff King
2016-06-15  7:17                                 ` Michael J Gruber
2016-06-16  9:25                                   ` Jeff King
2016-06-16 11:30                                     ` Michael J Gruber
2016-06-15  3:28                             ` Jeff King
2016-06-15  4:27             ` I lost my commit signature ZhenTian
2016-06-15  4:34               ` Jeff King
2016-06-15  7:07                 ` Michael J Gruber
2016-06-15 10:36                   ` ZhenTian
2016-06-16  7:34                   ` Jeff King
2016-06-16 17:06                     ` Junio C Hamano
2016-06-17  8:18                       ` Michael J Gruber
2016-06-17 16:39                         ` Junio C Hamano

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=3ccf7649-be0e-dcb8-c9a7-cdc36dc85d16@drmicha.warpmail.net \
    --to=git@drmicha.warpmail.net \
    --cc=git@vger.kernel.org \
    --cc=loooseleaves@gmail.com \
    --cc=peff@peff.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.