From owner-freebsd-security@FreeBSD.ORG Fri Sep 23 02:34:48 2011 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5B1FA106566C for ; Fri, 23 Sep 2011 02:34:48 +0000 (UTC) (envelope-from kaduk@mit.edu) Received: from dmz-mailsec-scanner-4.mit.edu (DMZ-MAILSEC-SCANNER-4.MIT.EDU [18.9.25.15]) by mx1.freebsd.org (Postfix) with ESMTP id 0ACEB8FC0A for ; Fri, 23 Sep 2011 02:34:47 +0000 (UTC) X-AuditID: 1209190f-b7b44ae000000a24-3c-4e7bec24a4b3 Received: from mailhub-auth-3.mit.edu ( [18.9.21.43]) by dmz-mailsec-scanner-4.mit.edu (Symantec Messaging Gateway) with SMTP id E4.0D.02596.42CEB7E4; Thu, 22 Sep 2011 22:17:08 -0400 (EDT) Received: from outgoing.mit.edu (OUTGOING-AUTH.MIT.EDU [18.7.22.103]) by mailhub-auth-3.mit.edu (8.13.8/8.9.2) with ESMTP id p8N2JiaA028370; Thu, 22 Sep 2011 22:19:44 -0400 Received: from multics.mit.edu (MULTICS.MIT.EDU [18.187.1.73]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.6/8.12.4) with ESMTP id p8N2Jfhq011837 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 22 Sep 2011 22:19:42 -0400 (EDT) Received: (from kaduk@localhost) by multics.mit.edu (8.12.9.20060308) id p8N2Jfcv027699; Thu, 22 Sep 2011 22:19:41 -0400 (EDT) Date: Thu, 22 Sep 2011 22:19:41 -0400 (EDT) From: Benjamin Kaduk To: d@delphij.net In-Reply-To: <4E792DEF.30209@delphij.net> Message-ID: References: <86boukbk8s.fsf@ds4.des.no> <4E738794.4050908@delphij.net> <86zki1afto.fsf@ds4.des.no> <4E78EA46.2080806@delphij.net> <86ty86zzcg.fsf@ds4.des.no> <1251419684.20110921022541@serebryakov.spb.ru> <4E7914E1.6040408@delphij.net> <849327678.20110921024347@serebryakov.spb.ru> <20110920225109.GF1511@deviant.kiev.zoral.com.ua> <4E792DEF.30209@delphij.net> User-Agent: Alpine 1.10 (GSO 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrDIsWRmVeSWpSXmKPExsUixCmqravyptrPYME9I4vjO4wsejY9YXNg 8vg/6w6Tx4xP81kCmKK4bFJSczLLUov07RK4Mk7vXcFScJ6rYmPnAfYGxs0cXYycHBICJhLL /3exQNhiEhfurWfrYuTiEBLYxygxfflGZghnA6PEjr/roDIHmCR+P9nJBOE0MErMvL6UGaSf RUBbYkr7BTCbTUBFYuabjUAdHBwiAoIS/9bEg4SZBRQk3j8+yQRiCwtISKy/uY0VpIRTQFPi fjsvSJhXwF7i7qFGRojxr5gkJn1YCzZSVEBHYvX+KSwQRYISJ2c+YYGYaSlx7s91tgmMgrOQ pGYhSS1gZFrFKJuSW6Wbm5iZU5yarFucnJiXl1qka6KXm1mil5pSuokRHKiS/DsYvx1UOsQo wMGoxMN7M7baT4g1say4MvcQoyQHk5Io79dXQCG+pPyUyozE4oz4otKc1OJDjBIczEoivO6X gXK8KYmVValF+TApaQ4WJXHexh0OfkIC6YklqdmpqQWpRTBZGQ4OJQneBGBECgkWpaanVqRl 5pQgpJk4OEGG8wANDwep4S0uSMwtzkyHyJ9iVJQS5zUESQiAJDJK8+B6YYnkFaM40CvCvLEg VTzAJATX/QpoMBPQYKXCSpDBJYkIKakGRts25W+9RZcCXv7km659W9PRosBhSXPJD47PJxb9 YFndeb6MsUjQlMel3zH5T8XW03af6pu2pZ7RC/60YkaWk4LgXbV2Vr505sxeq/uhm71Seu9M MV0Vsm6f5eGKz07lctYPLGvTdra1dZe1/H1/9LL8xeC4fS5mb3hu8+kVrY2OcbqxI+mVEktx RqKhFnNRcSIAMsgv1f8CAAA= Cc: freebsd-security@freebsd.org Subject: Re: PAM modules X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Sep 2011 02:34:48 -0000 On Tue, 20 Sep 2011, Xin LI wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA256 > > On 09/20/11 15:51, Kostik Belousov wrote: > [...] >> Yes, the question of maintanence of the OpenLDAP code in the base >> is not trivial by any means. I remember that openldap once broke >> the ABI on its stable-like branch. > > That happen a few times however these are either not essential client > library (libldap and liblber) API or it's not changing parameters or > removing interfaces. Moreover, like the base libbsdxml.so, it's only > intended to be used by base system only so it's relatively easier to > maintain ABI stability, e.g. we can probably just expose only symbols > that we use, etc. This is not without its own failures. For example, I sometimes find myself wanting a kgetcred(1) from heimdal, but we do not build it as part of our base heimdal. As a separate utility, this is not so bad; for a library, things can get much more annoying. Only exposing a limited set of symbols can make third-party tools that want extra symbols very sad, unless it is easy to drop in a full version from ports and still have all of base "just work". I do not quite think that the current state of ports for ldap would "just work" without some extra configuration (though, nor have I tried something like it). -Ben Kaduk