From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-3.3 required=5.0 tests=MAILING_LIST_MULTI, RCVD_IN_DNSWL_MED,RCVD_IN_MSPIKE_H3,RCVD_IN_MSPIKE_WL autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 25793 invoked from network); 23 Oct 2020 16:58:23 -0000 Received: from mother.openwall.net (195.42.179.200) by inbox.vuxu.org with ESMTPUTF8; 23 Oct 2020 16:58:23 -0000 Received: (qmail 9587 invoked by uid 550); 23 Oct 2020 16:58:16 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Reply-To: musl@lists.openwall.com Received: (qmail 9559 invoked from network); 23 Oct 2020 16:58:16 -0000 Date: Fri, 23 Oct 2020 12:58:03 -0400 From: Rich Felker To: Jesse Hathaway Cc: musl@lists.openwall.com, Arjun Shankar , Florian Weimer , Carlos O'Donell Message-ID: <20201023165802.GA534@brightrain.aerifal.cx> References: <1924902939.18027073.1603105167534.JavaMail.zimbra@redhat.com> <805098991.18032044.1603106011330.JavaMail.zimbra@redhat.com> <20201020010855.GE17637@brightrain.aerifal.cx> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [musl] Plans to remove nscd in Fedora On Fri, Oct 23, 2020 at 09:14:01AM -0500, Jesse Hathaway wrote: > On Fri, Oct 23, 2020 at 8:29 AM Carlos O'Donell wrote: > > My opinion is that we want something much thinner than nscd to provide > > NSS for statically linked applications, and that such an interface > > should not provide caching. If we really wanted we could keep the nscd > > socket interface but implement an NSS daemon for this e.g. nssd that would > > just run all the time and could be depended upon by static applications. > > It would have to be well audited and very simple. > > > > The caching that nscd does has many legacy problems that are better solved > > and maintained by other daemons that implement a split NSS module approach > > (as Florian notes). > > Given the increasing prevalence of statically deployed programs from languages > such as C, Go, Rust, and even Haskell. I would love to see continued > distribution support for querying NSS from these programs. An nscd variant > without caching seems like a good approach, but I think it would be unfortunate > to remove nscd from distributions before an alternative approach was available. Yes! As Laurent also noted, the real value here is maintaining the continuity of having a common, widely-deployed protocol and interface to perform NSS queries over. This doesn't necessitate keeping nscd permanently but does mean it should be removed only at the same time a replacement is deployed. Rich