From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754907AbcBHQkA (ORCPT ); Mon, 8 Feb 2016 11:40:00 -0500 Received: from e23smtp02.au.ibm.com ([202.81.31.144]:60799 "EHLO e23smtp02.au.ibm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753627AbcBHQj6 (ORCPT ); Mon, 8 Feb 2016 11:39:58 -0500 X-IBM-Helo: d23dlp01.au.ibm.com X-IBM-MailFrom: zohar@linux.vnet.ibm.com X-IBM-RcptTo: keyrings@vger.kernel.org;linux-kernel@vger.kernel.org;linux-security-module@vger.kernel.org Message-ID: <1454949543.2648.220.camel@linux.vnet.ibm.com> Subject: Re: [RFC PATCH 02/20] KEYS: Add a system blacklist keyring [ver #2] From: Mimi Zohar To: David Howells Cc: linux-security-module@vger.kernel.org, keyrings@vger.kernel.org, petkan@mip-labs.com, linux-kernel@vger.kernel.org Date: Mon, 08 Feb 2016 11:39:03 -0500 In-Reply-To: <32306.1454943347@warthog.procyon.org.uk> References: <1454938472.2648.173.camel@linux.vnet.ibm.com> <1453318283.2858.27.camel@linux.vnet.ibm.com> <20160119113026.23238.4498.stgit@warthog.procyon.org.uk> <20160119113041.23238.44728.stgit@warthog.procyon.org.uk> <24522.1454513272@warthog.procyon.org.uk> <32306.1454943347@warthog.procyon.org.uk> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.12.11 (3.12.11-1.fc21) Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-TM-AS-MML: disable X-Content-Scanned: Fidelis XPS MAILER x-cbid: 16020816-0005-0000-0000-0000034620CA Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, 2016-02-08 at 14:55 +0000, David Howells wrote: > Mimi Zohar wrote: > > > By separating out the blacklist keyring from the issue of trust, you'll have > > smaller patch sets that can more easily be reviewed. (Reviewing anything > > having to do with certificates is difficult enough.) It would also allow > > you to upstream the two patch sets independently of each other. > > Unfortunately, there's a dependency between the subsets you're talking about > in the form of the restriction function passed to keyring_alloc() - an > argument that's only made available in the other subset, so they cannot be > completely independent. > > That said, the trust changes don't require the blacklist changes. Right, I should have said the blacklist changes are dependent on the trusted keyring changes. In the "trust" patch set, could you please include Mehmet's patch? Thanks! Mimi