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.1 required=5.0 tests=DKIM_INVALID,DKIM_SIGNED, 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 27148 invoked from network); 23 Oct 2020 12:09:27 -0000 Received: from mother.openwall.net (195.42.179.200) by inbox.vuxu.org with ESMTPUTF8; 23 Oct 2020 12:09:27 -0000 Received: (qmail 1980 invoked by uid 550); 23 Oct 2020 12:09:25 -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 1955 invoked from network); 23 Oct 2020 12:09:24 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1603454952; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=fi3HrSEQp/ZnSCcgCKLi0r8wiKyG/6ITLrdTP9rskvY=; b=ifbVOmN8pICJHcDoC6rWS4X7HluGfYEXGxRyvmM5tzyi/Ji7WgEQuVii908YA4miQSB8SD Ug+Dp/h8Hw/1wrj7IVDRAuKwRmVgBwZ4XqM6X9gjJyCQ/qAmytO3Z5YocmNLGY5LLEj9t6 BCbcS1KibvVv73Ov6lWqabPG+ubI8Z4= X-MC-Unique: Bhtk_oXnMha3Tj2zT50enA-1 From: Florian Weimer To: Tim Tassonis Cc: musl@lists.openwall.com References: <1924902939.18027073.1603105167534.JavaMail.zimbra@redhat.com> <805098991.18032044.1603106011330.JavaMail.zimbra@redhat.com> <20201020010855.GE17637@brightrain.aerifal.cx> <87pn59i38j.fsf@oldenburg2.str.redhat.com> <514e3157-f82b-8417-e748-16e9539ecacd@decentral.ch> Date: Fri, 23 Oct 2020 14:09:07 +0200 In-Reply-To: <514e3157-f82b-8417-e748-16e9539ecacd@decentral.ch> (Tim Tassonis's message of "Fri, 23 Oct 2020 14:01:00 +0200") Message-ID: <87h7qli1p8.fsf@oldenburg2.str.redhat.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.1 (gnu/linux) MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.84 on 10.5.11.23 Authentication-Results: relay.mimecast.com; auth=pass smtp.auth=CUSA124A263 smtp.mailfrom=fweimer@redhat.com X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain Subject: Re: [musl] Plans to remove nscd in Fedora * Tim Tassonis: > On 10/23/20 1:35 PM, Florian Weimer wrote: >> * Rich Felker: >> >>> The only capacity in which musl uses nscd is to access custom >>> user/group backends provided through it. >> And that's the only way to get this data into musl programs. >> >>> musl specifically does not use nss itself because it's not compatible >>> with static linking and because loading arbitrary module libraries >>> into the calling process's core is not safe and goes against best >>> practices. I believe the glibc folks were starting to realize this >>> too, so it was kinda my hope that nscd would become the main/only way >>> nss modules are accessed on glibc too. >> This requirement has largely been pushed into the NSS modules >> themselves. If they do more than just opening a files or sockets, they >> need to offload part of the functionality (actually most of it) into a >> separate daemon. This is the difference between nss_ldap and nss_ldapd. >> SSSD has largely assumed this role for the non-hosts maps. It looks >> like that systemd-resolved will cover the hosts maps. So it's unclear >> what's left for nscd to handle. > > You might not know about this, but there is actually a world beyond > Redhat/Fedora/Systemd. Yes, we know that. Which is why Arjun reached out to you. Was this a mistake? Is the musl community not interested in compatibility with Fedora and its downstream distributions? Thanks, Florian -- Red Hat GmbH, https://de.redhat.com/ , Registered seat: Grasbrunn, Commercial register: Amtsgericht Muenchen, HRB 153243, Managing Directors: Charles Cachera, Brian Klemm, Laurie Krebs, Michael O'Neill