From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1757742AbcBSL4w (ORCPT ); Fri, 19 Feb 2016 06:56:52 -0500 Received: from mx1.redhat.com ([209.132.183.28]:55588 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1757710AbcBSL4t (ORCPT ); Fri, 19 Feb 2016 06:56:49 -0500 Organization: Red Hat UK Ltd. Registered Address: Red Hat UK Ltd, Amberley Place, 107-111 Peascod Street, Windsor, Berkshire, SI4 1TE, United Kingdom. Registered in England and Wales under Company Registration No. 3798903 From: David Howells In-Reply-To: <1454932855.2648.146.camel@linux.vnet.ibm.com> References: <1454932855.2648.146.camel@linux.vnet.ibm.com> <20160119113026.23238.4498.stgit@warthog.procyon.org.uk> <20160119113155.23238.51376.stgit@warthog.procyon.org.uk> To: Mimi Zohar Cc: dhowells@redhat.com, linux-security-module@vger.kernel.org, keyrings@vger.kernel.org, petkan@mip-labs.com, linux-kernel@vger.kernel.org Subject: Re: [RFC PATCH 12/20] PKCS#7: Make the signature a pointer rather than embedding it [ver #2] MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <30168.1455883006.1@warthog.procyon.org.uk> Date: Fri, 19 Feb 2016 11:56:46 +0000 Message-ID: <30169.1455883006@warthog.procyon.org.uk> Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Mimi Zohar wrote: > > Point to the public_key_signature struct from the pkcs7_signed_info struct > > rather than embedding it. This makes it easier to have it take an > > arbitrary number of MPIs in future. > > Just a reminder ... > > Reviewing patches isn't easy no matter how well written and documented, > especially large patch sets. For this reason, patch sets should be > limited to the patches that are required to accomplish the patch set > goal. In this case, that goal is to change "how certificates/keys are > determined to be trusted." > > Although this patch is straight forward, the patch description should > include a reason for including this patch in this patch set. Is having > an arbitrary number of MPIs included in this patch set? Could this > patch be deferred? Actually, this may be changed with the advent of Tadeusz's patches. David