From mboxrd@z Thu Jan 1 00:00:00 1970 From: Michael J Gruber Subject: Re: [PATCH 3/3] verify-commit: scriptable commit signature verification Date: Fri, 27 Jun 2014 14:49:30 +0200 Message-ID: <53AD685A.1030401@drmicha.warpmail.net> References: <20140613080229.GJ7908@sigill.intra.peff.net> <539ACA8A.90108@drmicha.warpmail.net> <20140613110901.GB14066@sigill.intra.peff.net> <20140616195428.GB24376@sigill.intra.peff.net> <20140616203956.GA3546@sigill.intra.peff.net> <53AD640A.9060006@drmicha.warpmail.net> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: git@vger.kernel.org To: Jeff King , Junio C Hamano X-From: git-owner@vger.kernel.org Fri Jun 27 14:49:40 2014 Return-path: Envelope-to: gcvg-git-2@plane.gmane.org Received: from vger.kernel.org ([209.132.180.67]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1X0Vb0-0006B5-33 for gcvg-git-2@plane.gmane.org; Fri, 27 Jun 2014 14:49:38 +0200 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753189AbaF0Mte (ORCPT ); Fri, 27 Jun 2014 08:49:34 -0400 Received: from out1-smtp.messagingengine.com ([66.111.4.25]:46614 "EHLO out1-smtp.messagingengine.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752306AbaF0Mtd (ORCPT ); Fri, 27 Jun 2014 08:49:33 -0400 Received: from compute2.internal (compute2.nyi.mail.srv.osa [10.202.2.42]) by gateway1.nyi.mail.srv.osa (Postfix) with ESMTP id DB3AE2167E; Fri, 27 Jun 2014 08:49:32 -0400 (EDT) Received: from frontend2 ([10.202.2.161]) by compute2.internal (MEProxy); Fri, 27 Jun 2014 08:49:32 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=message-id:date:from:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; s=smtpout; bh=tGWKMlTOJ5DqF7myAO2a3t 5BgTA=; b=qoowJQ9Y+dYP+Orw8I4zvFt5/Q6fmuzYjarAz36IrwhxWL5ngGY0Ia dy4nKb+adWMoKDJZV6k5xdMfDqLOVqgXxAZfUP26SkrHsbWuCzPyerNZVjEQxmzr 4MlAp3DlTlCFoQC3oLzZj+sQpWTCgULNzLiDzf1uN+gA65r5yR1Nw= X-Sasl-enc: Jn1wiRERdEKS7KS9OQIh9I1idYuDD6apBXTF1PXikJ7s 1403873371 Received: from localhost.localdomain (unknown [130.75.46.56]) by mail.messagingengine.com (Postfix) with ESMTPA id 1C15C680214; Fri, 27 Jun 2014 08:49:31 -0400 (EDT) User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 In-Reply-To: <53AD640A.9060006@drmicha.warpmail.net> Sender: git-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: git@vger.kernel.org Archived-At: Michael J Gruber venit, vidit, dixit 27.06.2014 14:31: > Jeff King venit, vidit, dixit 16.06.2014 22:39: >> On Mon, Jun 16, 2014 at 01:34:20PM -0700, Junio C Hamano wrote: >> >>>> Your middle example above did make me think of one other thing, though. >>>> As you noted, we actually have _three_ signature types: >>>> >>>> 1. signed tags >>>> >>>> 2. signed commits >>>> >>>> 3. merges with embedded mergetag headers >>>> >>>> We already have a tool for (1). Michael is adding a tool for (2). How >>>> would one check (3) in a similar way? >>> >>> Hmph, somehow I misread the patch that it was for both 2 & 3 X-<. >> >> I was just assuming it handles only (2) without checking further, so I >> may be wrong. But I do not think it makes sense to conflate (2) and (3). >> A merge commit may have both, and they are separate signatures. >> >> For that matter, is there a way to expose (3) currently, besides via >> --show-signature? It does not trigger "%GG" and friends (nor should it). >> It may make sense to add extra format specifiers for mergetag >> signatures. Though I do not use them myself, so I am not clear on what >> the use case is besides a manual, human verification of a particular >> merge. > > I'm afraid I'm on a weekly git schedule at best, sorry. Just trying to > catch up on this: > > Admittedly, I simply don't know about "3.". I know only 1. and 2. (and > don't remember why they are implemented differently). > > Are they documented/decribed somewhere? > > Meanwhile, I'm rebasing on top of the %G related patches by Junio and > Jeff and hope to send out a v4 later today. > > Michael OK, found the two commits which "git log -Smergetag" outputs, but no tests. A merge commit with embedded signed tag it is, then. The commit could carry it's own commit signature, couldn't it? That would suggest that we use "git verify-tag" to verify the embedded signed tag of a merge commit and "git verify-commit" to verify the commit signature. OTOH I would like these basic commands to be as strict as possible, including type-checks. Does that mean having "git verify-mergetag" which verifies that it is being used on a merge commit with embedded mergetag? (BTW: Is there anything keeping a non-merge commit from having an embedded (merge) tag?) Michael