This message generated a parse failure. Raw output follows here. Please use 'back' to navigate. From devnull@lkml.org Sun May 19 02:24:25 2024 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S262197AbTJ3EqU (ORCPT ); Wed, 29 Oct 2003 23:46:20 -0500 Received: from mx1.redhat.com ([66.187.233.31]:14088 "EHLO mx1.redhat.com") by vger.kernel.org with ESMTP id S262196AbTJ3EqT (ORCPT ); Wed, 29 Oct 2003 23:46:19 -0500 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.11.6/8.11.6) with ESMTP id h9U4kFM13616; Wed, 29 Oct 2003 23:46:15 -0500 Received: from mail.boston.redhat.com (mail.boston.redhat.com [172.16.64.12]) by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id h9U4kE632321; Wed, 29 Oct 2003 23:46:14 -0500 Received: from thoron.boston.redhat.com (thoron.boston.redhat.com [172.16.65.238]) by mail.boston.redhat.com (8.12.8/8.12.8) with ESMTP id h9U4kE4s026124; Wed, 29 Oct 2003 23:46:14 -0500 Date: Wed, 29 Oct 2003 23:47:05 -0500 (EST) From: James Morris X-X-Sender: jmorris@thoron.boston.redhat.com To: YOSHIFUJI Hideaki / =?iso-2022-jp?B?GyRCNUhGIzFRTEAbKEI=?= Cc: paulus@samba.org, , , Subject: Re: Bug somewhere in crypto or ipsec stuff In-Reply-To: <20031030.124124.26191552.yoshfuji@linux-ipv6.org> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org On Thu, 30 Oct 2003, YOSHIFUJI Hideaki / [iso-2022-jp] 吉藤英明 wrote: > In article (at Wed, 29 Oct 2003 22:22:50 -0500 (EST)), James Morris says: > > > On Thu, 30 Oct 2003, YOSHIFUJI Hideaki / [iso-2022-jp] 吉藤英明 wrote: > > > > > > > I would just disallow name == NULL, > > > well, what algorithm do you expect? > > > > Good question. It seems to me to be a bug in the calling code if it is > > trying to look up nothing -- I'd rather not paper that over. > > Do you mean that we need to fix the caller? Yes. > > Well, people may want to get just any algorithm. > In such case, > - crypto allows name == NULL, and return any algorithm > (for example, an algorithm that we see first.) > - caller may filter name == NULL case if it is ambiguous in their context. I think that could be dangerous, including if calling with null is a bug, and they get an inappropriate algorithm. An incorrect algorithm type could also be returned (e.g. digest instead of a cipher). - James -- James Morris - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/