From owner-freebsd-security@FreeBSD.ORG Mon Jun 1 01:38:59 2015 Return-Path: Delivered-To: freebsd-security@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id F10F8644 for ; Mon, 1 Jun 2015 01:38:59 +0000 (UTC) (envelope-from truckman@FreeBSD.org) Received: from gw.catspoiler.org (cl-1657.chi-02.us.sixxs.net [IPv6:2001:4978:f:678::2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id A08E11170 for ; Mon, 1 Jun 2015 01:38:59 +0000 (UTC) (envelope-from truckman@FreeBSD.org) Received: from FreeBSD.org (mousie.catspoiler.org [192.168.101.2]) by gw.catspoiler.org (8.13.3/8.13.3) with ESMTP id t511cp2P088983 for ; Sun, 31 May 2015 18:38:55 -0700 (PDT) (envelope-from truckman@FreeBSD.org) Message-Id: <201506010138.t511cp2P088983@gw.catspoiler.org> Date: Sun, 31 May 2015 17:21:49 -0700 (PDT) From: Don Lewis Subject: avoiding base openssl when building ports To: freebsd-security@FreeBSD.org MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Jun 2015 01:39:00 -0000 After all the noise about base openssl vs. ports openssl on this list a couple of weeks ago, I bit the bullet and tossed WITH_OPENSSL_PORT=yes in poudriere.d/*-make.conf and kicked off a poudriere run. It chugged for quite a while and rebuilt lots of ports. After it was done, I ran pkg upgrade and was dismayed when I discovered that ldd told me that quite a few executables were linked to openssl in base. The big culprit turned out to be ftp/curl. Even though WITH_OPENSSL_PORT=yes caused it to add the openssl port as a build and run dependency, it was silently getting linked to openssl from base. The cause of that problem is that the default GSSAPI_BASE option adds -L/usr/lib near the start of LDFLAGS, so the linker finds the base openssl libraries instead of the ones from the port. I worked around that problem by switching to GSSAPI_NONE, though I tested that the other GSSAPI_* options also work correctly. There is a sanity check in the Makefile that attempts to catch this conflict, but it does not work correctly. See . After another poudriere run, which rebuilt the curl package and everything that depended on it, things were looking much better. Of my ~1300 installed ports, I only found two other problematic ports: www/links1 and security/nmap The only remaining port that links to openssl in base is pkg, which I think is mandatory for chicken vs. egg reasons. I'm currently running with these updated ports and haven't run into any problems. From owner-freebsd-security@FreeBSD.ORG Mon Jun 1 16:17:44 2015 Return-Path: Delivered-To: freebsd-security@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 4F59A305; Mon, 1 Jun 2015 16:17:44 +0000 (UTC) (envelope-from kaduk@mit.edu) Received: from dmz-mailsec-scanner-2.mit.edu (dmz-mailsec-scanner-2.mit.edu [18.9.25.13]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id CB2051F28; Mon, 1 Jun 2015 16:17:43 +0000 (UTC) (envelope-from kaduk@mit.edu) X-AuditID: 1209190d-f79526d000000ed5-ef-556c859ec676 Received: from mailhub-auth-2.mit.edu ( [18.7.62.36]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-2.mit.edu (Symantec Messaging Gateway) with SMTP id 0B.54.03797.E958C655; Mon, 1 Jun 2015 12:17:34 -0400 (EDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-2.mit.edu (8.13.8/8.9.2) with ESMTP id t51GHXh9031792; Mon, 1 Jun 2015 12:17:34 -0400 Received: from multics.mit.edu (system-low-sipb.mit.edu [18.187.2.37]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id t51GHWUd019512 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 1 Jun 2015 12:17:33 -0400 Received: (from kaduk@localhost) by multics.mit.edu (8.12.9.20060308) id t51GHVbC024695; Mon, 1 Jun 2015 12:17:31 -0400 (EDT) Date: Mon, 1 Jun 2015 12:17:31 -0400 (EDT) From: Benjamin Kaduk To: Don Lewis cc: freebsd-security@FreeBSD.org Subject: Re: avoiding base openssl when building ports In-Reply-To: <201506010138.t511cp2P088983@gw.catspoiler.org> Message-ID: References: <201506010138.t511cp2P088983@gw.catspoiler.org> User-Agent: Alpine 1.10 (GSO 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrOIsWRmVeSWpSXmKPExsUixG6nojuvNSfUYOYcfYueTU/YLE42NbM6 MHnM+DSfJYAxissmJTUnsyy1SN8ugSuj8a1ywQKuiuPbpzM1MC7m6GLk5JAQMJHYseYfO4Qt JnHh3nq2LkYuDiGBxUwSR2ZeZIFwNjBKnG5aBpU5yCTx/Pl0JpAWIYF6ibmTu9lAbBYBLYn9 XyaD2WwCKhIz32wEs0WA7Ik9f1lAbGYBBYlZr76BxYUFzCRO/vjDCmJzCthIPFl7BCzOK+Ao 0bv3FTPEfGuJriWzwGpEBXQkVu+fwgJRIyhxcuYTqJlaEsunb2OZwCg4C0lqFpLUAkamVYyy KblVurmJmTnFqcm6xcmJeXmpRbpGermZJXqpKaWbGEHhySnJu4Px3UGlQ4wCHIxKPLwZ3dmh QqyJZcWVuYcYJTmYlER5nStzQoX4kvJTKjMSizPii0pzUosPMUpwMCuJ8Mo2AeV4UxIrq1KL 8mFS0hwsSuK8m37whQgJpCeWpGanphakFsFkZTg4lCR47VqAGgWLUtNTK9Iyc0oQ0kwcnCDD eYCGl4DU8BYXJOYWZ6ZD5E8xKkqJ8y4ESQiAJDJK8+B6YenjFaM40CvCvNuagap4gKkHrvsV 0GAmoMHtAmCDSxIRUlINjL7WvXnX91xfu7Fq+9F9nGL7d3YV5B678+t4YnaLWuDFn+fZFD6e f+gvudViswjHXz+GrXOnJanuSYz8/MDutar5sg9f9BaHrjjoJXJC2fXhepcTDafuKB+0vSwb HLjdLTEx3EXM/KSDX+BpMd+Zdt9X1mX+el/M++DTnEAG8RDZt28PSl5f6qLEUpyRaKjFXFSc CABZwFOB+gIAAA== X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Jun 2015 16:17:44 -0000 On Sun, 31 May 2015, Don Lewis wrote: > The big culprit turned out to be ftp/curl. Even though > WITH_OPENSSL_PORT=yes caused it to add the openssl port as a build and > run dependency, it was silently getting linked to openssl from base. The > cause of that problem is that the default GSSAPI_BASE option adds > -L/usr/lib near the start of LDFLAGS, so the linker finds the base > openssl libraries instead of the ones from the port. I worked around > that problem by switching to GSSAPI_NONE, though I tested that the other > GSSAPI_* options also work correctly. There is a sanity check in the > Makefile that attempts to catch this conflict, but it does not work > correctly. See > . My apologies for semi-hijacking your thread, but I am starting to wonder whether the base Heimdal (and GSSAPI) should be converted to be a private library. Since I am living in a MIT krb5 world, which is incompatible with the Heimdal libraries, I end up having some trouble trying to force various things to be used from base vs. ports. Making the Heimdal in base into private libraries would "solve" the problem with ftp/curl, but only insamuch as it would make the GSSAPI_BASE option useless and require a GSSAPI from ports. -Ben From owner-freebsd-security@FreeBSD.ORG Mon Jun 1 16:25:04 2015 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 11A8F546; Mon, 1 Jun 2015 16:25:04 +0000 (UTC) (envelope-from kpaasial@gmail.com) Received: from mail-la0-x232.google.com (mail-la0-x232.google.com [IPv6:2a00:1450:4010:c03::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 8DD64117E; Mon, 1 Jun 2015 16:25:03 +0000 (UTC) (envelope-from kpaasial@gmail.com) Received: by labko7 with SMTP id ko7so102133328lab.2; Mon, 01 Jun 2015 09:25:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=DlFmibljXXDmNphfWX9VacM614Ug8hepqeTPoeGZQ6Q=; b=LHLz4qFHO8dIC53R76rUzeDBURYlWaGCswkUdqbH7mC8caiddvIdSyPt1aMGeGWlmD GPK0PQTjtuKEzy7ZCoN3Q0n9kVsHbOEgBwOaDmkGsFNOquf+LxC4OQPxHsuEh5uUBip+ klPiAIPftNWsesF+7IwXSWihDmmCJvwEnjEPtH53+VbRLwB971lq79MBcUvE44UdKChw xr7Aqt/qEjZbPAnFfDYgOPmzwo+UJPrXpR+IqR0jH+l88bTCMUGfoiYxhIBddjwR0sT6 BV7uKg8B2+/2zyhuc9I9bs4JAwtlVD/LOBXKQIBEJ/1Ch8SIxxR+79jli/EoI83LQ/Bg +YYQ== MIME-Version: 1.0 X-Received: by 10.152.116.113 with SMTP id jv17mr21859511lab.28.1433175901660; Mon, 01 Jun 2015 09:25:01 -0700 (PDT) Received: by 10.152.137.193 with HTTP; Mon, 1 Jun 2015 09:25:01 -0700 (PDT) In-Reply-To: References: <201506010138.t511cp2P088983@gw.catspoiler.org> Date: Mon, 1 Jun 2015 19:25:01 +0300 Message-ID: Subject: Re: avoiding base openssl when building ports From: Kimmo Paasiala To: Benjamin Kaduk Cc: Don Lewis , freebsd-security Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Jun 2015 16:25:04 -0000 On Mon, Jun 1, 2015 at 7:17 PM, Benjamin Kaduk wrote: > On Sun, 31 May 2015, Don Lewis wrote: > >> The big culprit turned out to be ftp/curl. Even though >> WITH_OPENSSL_PORT=yes caused it to add the openssl port as a build and >> run dependency, it was silently getting linked to openssl from base. The >> cause of that problem is that the default GSSAPI_BASE option adds >> -L/usr/lib near the start of LDFLAGS, so the linker finds the base >> openssl libraries instead of the ones from the port. I worked around >> that problem by switching to GSSAPI_NONE, though I tested that the other >> GSSAPI_* options also work correctly. There is a sanity check in the >> Makefile that attempts to catch this conflict, but it does not work >> correctly. See >> . > > My apologies for semi-hijacking your thread, but I am starting to wonder > whether the base Heimdal (and GSSAPI) should be converted to be a private > library. Since I am living in a MIT krb5 world, which is incompatible > with the Heimdal libraries, I end up having some trouble trying to force > various things to be used from base vs. ports. > > Making the Heimdal in base into private libraries would "solve" the > problem with ftp/curl, but only insamuch as it would make the GSSAPI_BASE > option useless and require a GSSAPI from ports. > > -Ben Rumour is that something like that is going to happen with all of the problematic libraries by making them private. If someone with inside knowledge could confirm these rumours? ;) This leads to another question. Where is the line going to be drawn which libraries in the base system should be private? There are certainly some of them that have to be public like libc and the support libraries like libusb. There is certainly no sense in making the ports system use full set of its own libraries for everything either. -Kimmo From owner-freebsd-security@FreeBSD.ORG Mon Jun 1 16:34:47 2015 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id CFFF9780 for ; Mon, 1 Jun 2015 16:34:47 +0000 (UTC) (envelope-from marquis@roble.com) Received: from mx5.roble.com (mx5.roble.com [206.40.34.5]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mx5.roble.com", Issuer "mx5.roble.com" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id BFF4F1465 for ; Mon, 1 Jun 2015 16:34:47 +0000 (UTC) (envelope-from marquis@roble.com) Date: Mon, 1 Jun 2015 09:34:40 -0700 (PDT) From: Roger Marquis To: freebsd-security Subject: Re: avoiding base openssl when building ports In-Reply-To: References: <201506010138.t511cp2P088983@gw.catspoiler.org> User-Agent: Alpine 2.11 (BSF 23 2013-08-11) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Jun 2015 16:34:47 -0000 Kimmo Paasiala: > Rumour is that something like that is going to happen with all of the > problematic libraries by making them private. If someone with inside > knowledge could confirm these rumours? ;) Curious why this is a rumor? Open source operating systems should be developed transparently, shouldn't they? > This leads to another question. Where is the line going to be drawn > which libraries in the base system should be private? There are > certainly some of them that have to be public like libc and the > support libraries like libusb. There is certainly no sense in making > the ports system use full set of its own libraries for everything > either. I'd be happy just to to 'make buildworld -DWITHOUT_OPENSSL'. Roger Marquis From owner-freebsd-security@FreeBSD.ORG Mon Jun 1 16:43:33 2015 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 953A791E for ; Mon, 1 Jun 2015 16:43:33 +0000 (UTC) (envelope-from kaduk@mit.edu) Received: from dmz-mailsec-scanner-6.mit.edu (dmz-mailsec-scanner-6.mit.edu [18.7.68.35]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 3FA3C16C9 for ; Mon, 1 Jun 2015 16:43:32 +0000 (UTC) (envelope-from kaduk@mit.edu) X-AuditID: 12074423-f79496d000000d43-47-556c8a80fd58 Received: from mailhub-auth-4.mit.edu ( [18.7.62.39]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-6.mit.edu (Symantec Messaging Gateway) with SMTP id 0C.61.03395.08A8C655; Mon, 1 Jun 2015 12:38:24 -0400 (EDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-4.mit.edu (8.13.8/8.9.2) with ESMTP id t51GcNAx021130; Mon, 1 Jun 2015 12:38:24 -0400 Received: from multics.mit.edu (system-low-sipb.mit.edu [18.187.2.37]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id t51GcLCS026412 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 1 Jun 2015 12:38:23 -0400 Received: (from kaduk@localhost) by multics.mit.edu (8.12.9.20060308) id t51GcLTm027282; Mon, 1 Jun 2015 12:38:21 -0400 (EDT) Date: Mon, 1 Jun 2015 12:38:21 -0400 (EDT) From: Benjamin Kaduk To: Roger Marquis cc: freebsd-security Subject: Re: avoiding base openssl when building ports In-Reply-To: <20150601163453.340DA782@hub.freebsd.org> Message-ID: References: <201506010138.t511cp2P088983@gw.catspoiler.org> <20150601163453.340DA782@hub.freebsd.org> User-Agent: Alpine 1.10 (GSO 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrLIsWRmVeSWpSXmKPExsUixG6nrtvQlRNq8H6HokXPpidsFh0L3R2Y PGZ8ms/icez+arYApigum5TUnMyy1CJ9uwSujO2/njAWXOeo+HT+LlsD40e2LkZODgkBE4m5 l74yQ9hiEhfurQeKc3EICSxmkniz7hSUs4FR4tHHP4wQzkEmif2dh9hBWoQE6iXmHvrBBGKz CGhJ7Hi1khHEZhNQkZj5ZiPYChEBVYne02vBapgFjCUOLZ0EZgsLmEmc/PGHFcTmBLI7e36D 9fIKOEpc+fCIBWLZA0aJjh3dLCAJUQEdidX7p7BAFAlKnJz5hAViqJbE8unbWCYwCs5CkpqF JLWAkWkVo2xKbpVubmJmTnFqsm5xcmJeXmqRrplebmaJXmpK6SZGcKi6KO9g/HNQ6RCjAAej Eg9vRnd2qBBrYllxZe4hRkkOJiVRXufKnFAhvqT8lMqMxOKM+KLSnNTiQ4wSHMxKIryyTUA5 3pTEyqrUonyYlDQHi5I476YffCFCAumJJanZqakFqUUwWRkODiUJ3shOoEbBotT01Iq0zJwS hDQTByfIcB6g4fdBaniLCxJzizPTIfKnGBWlxHkngCQEQBIZpXlwvbBU8opRHOgVYd55IFU8 wDQE1/0KaDAT0OB2AbDBJYkIKakGRuNVzhurl9r0mPeLGL2e0XQx7nFjCHPHTC0lLruVzhcu s8cHrlo1WarmBVvoOrvHny9YLd965+ikFU6i8SKbFG7w2s81Wf5iUtGOt3s/Cfz9031g56nI nfYpL2dWmF0p2LPl+vNEuen8l4/9kefvOD/5zIH5H19Z7K22mz/RPOMbR/5bm7vutw2UWIoz Eg21mIuKEwGmRcreAAMAAA== X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Jun 2015 16:43:33 -0000 On Mon, 1 Jun 2015, Roger Marquis wrote: > Kimmo Paasiala: > > Rumour is that something like that is going to happen with all of the > > problematic libraries by making them private. If someone with inside > > knowledge could confirm these rumours? ;) > > Curious why this is a rumor? Open source operating systems should be > developed transparently, shouldn't they? I have no concrete data, but something might live as only a rumor if someone is considering making the change and analyzing how much work it would be, before they have any proposal to make or patches for review. > > This leads to another question. Where is the line going to be drawn > > which libraries in the base system should be private? There are > > certainly some of them that have to be public like libc and the > > support libraries like libusb. There is certainly no sense in making > > the ports system use full set of its own libraries for everything > > either. > > I'd be happy just to to 'make buildworld -DWITHOUT_OPENSSL'. Better to set WITHOUT_SSL=yes in /etc/src.conf (see src.conf(5)). -Ben From owner-freebsd-security@FreeBSD.ORG Mon Jun 1 16:44:56 2015 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id C12ACA1A for ; Mon, 1 Jun 2015 16:44:56 +0000 (UTC) (envelope-from julian@freebsd.org) Received: from vps1.elischer.org (vps1.elischer.org [204.109.63.16]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "vps1.elischer.org", Issuer "CA Cert Signing Authority" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 8D02816F0 for ; Mon, 1 Jun 2015 16:44:56 +0000 (UTC) (envelope-from julian@freebsd.org) Received: from Julian-MBP3.local (ppp121-45-248-228.lns20.per4.internode.on.net [121.45.248.228]) (authenticated bits=0) by vps1.elischer.org (8.14.9/8.14.9) with ESMTP id t51Giq7J096410 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO) for ; Mon, 1 Jun 2015 09:44:55 -0700 (PDT) (envelope-from julian@freebsd.org) Message-ID: <556C8BFE.708@freebsd.org> Date: Tue, 02 Jun 2015 00:44:46 +0800 From: Julian Elischer User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: freebsd-security@freebsd.org Subject: Re: avoiding base openssl when building ports References: <201506010138.t511cp2P088983@gw.catspoiler.org> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Jun 2015 16:44:56 -0000 On 6/2/15 12:25 AM, Kimmo Paasiala wrote: > On Mon, Jun 1, 2015 at 7:17 PM, Benjamin Kaduk wrote: >> On Sun, 31 May 2015, Don Lewis wrote: >> >>> The big culprit turned out to be ftp/curl. Even though >>> WITH_OPENSSL_PORT=yes caused it to add the openssl port as a build and >>> run dependency, it was silently getting linked to openssl from base. The >>> cause of that problem is that the default GSSAPI_BASE option adds >>> -L/usr/lib near the start of LDFLAGS, so the linker finds the base >>> openssl libraries instead of the ones from the port. I worked around >>> that problem by switching to GSSAPI_NONE, though I tested that the other >>> GSSAPI_* options also work correctly. There is a sanity check in the >>> Makefile that attempts to catch this conflict, but it does not work >>> correctly. See >>> . >> My apologies for semi-hijacking your thread, but I am starting to wonder >> whether the base Heimdal (and GSSAPI) should be converted to be a private >> library. Since I am living in a MIT krb5 world, which is incompatible >> with the Heimdal libraries, I end up having some trouble trying to force >> various things to be used from base vs. ports. >> >> Making the Heimdal in base into private libraries would "solve" the >> problem with ftp/curl, but only insamuch as it would make the GSSAPI_BASE >> option useless and require a GSSAPI from ports. >> >> -Ben > > Rumour is that something like that is going to happen with all of the > problematic libraries by making them private. If someone with inside > knowledge could confirm these rumours? ;) > > This leads to another question. Where is the line going to be drawn > which libraries in the base system should be private? There are > certainly some of them that have to be public like libc and the > support libraries like libusb. There is certainly no sense in making > the ports system use full set of its own libraries for everything > either. I'd like to take a bunch of libraries out of base, But That is not the same as making them "ports". I've said before that I thik we need something half way between. using the ports/pkg mechanism, but from an administrative point of view, still a part of base.. Easier to upgrade, but yet, still considered part of the base distribution. in other words, currently a failure in ncurses can stop a release from shipping, and in my world a failure in "base pkg ncurses" would still have that ability, but would be delivered as a separately upgradable pkg. i.e. some pkgs are more important than others. > > -Kimmo > _______________________________________________ > freebsd-security@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-security > To unsubscribe, send any mail to "freebsd-security-unsubscribe@freebsd.org" > > From owner-freebsd-security@FreeBSD.ORG Mon Jun 1 16:47:58 2015 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id F3B08C6A; Mon, 1 Jun 2015 16:47:57 +0000 (UTC) (envelope-from kaduk@mit.edu) Received: from dmz-mailsec-scanner-3.mit.edu (dmz-mailsec-scanner-3.mit.edu [18.9.25.14]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 89F28172F; Mon, 1 Jun 2015 16:47:57 +0000 (UTC) (envelope-from kaduk@mit.edu) X-AuditID: 1209190e-f79b96d000000e0e-34-556c8b87dbef Received: from mailhub-auth-4.mit.edu ( [18.7.62.39]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-3.mit.edu (Symantec Messaging Gateway) with SMTP id B2.8F.03598.78B8C655; Mon, 1 Jun 2015 12:42:47 -0400 (EDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-4.mit.edu (8.13.8/8.9.2) with ESMTP id t51GgkkX021685; Mon, 1 Jun 2015 12:42:47 -0400 Received: from multics.mit.edu (system-low-sipb.mit.edu [18.187.2.37]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id t51Ggj6n028013 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 1 Jun 2015 12:42:46 -0400 Received: (from kaduk@localhost) by multics.mit.edu (8.12.9.20060308) id t51GgifN027840; Mon, 1 Jun 2015 12:42:44 -0400 (EDT) Date: Mon, 1 Jun 2015 12:42:44 -0400 (EDT) From: Benjamin Kaduk To: Kimmo Paasiala cc: Don Lewis , freebsd-security Subject: scope of private libraries In-Reply-To: Message-ID: References: <201506010138.t511cp2P088983@gw.catspoiler.org> User-Agent: Alpine 1.10 (GSO 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrAIsWRmVeSWpSXmKPExsUixG6nrtvenRNqcOy/gUXPpidsFusOTGK2 ONnUzOrA7DHj03wWj52z7rIHMEVx2aSk5mSWpRbp2yVwZXQcmsBU8JKr4v/S/awNjHc4uhg5 OCQETCTmP6vpYuQEMsUkLtxbz9bFyMUhJLCYSWLrhQtMEM4GRombK26ygVQJCRxkknh+3wWk WUigXuLhOT+QMIuAlsT3Y6/AStgEVCRmvtkIZosIqEv0n5zFAmIzC8RJzL/5BiwuLKAssevW fGYQm1MgUOLT2mNgcV4BR4mXJ84zQ+zdxihx4OAasCJRAR2J1funsEAUCUqcnPkEaqiWxPLp 21gmMArOQpKahSS1gJFpFaNsSm6Vbm5iZk5xarJucXJiXl5qka6xXm5miV5qSukmRlDAckry 7WD8elDpEKMAB6MSD29Gd3aoEGtiWXFl7iFGSQ4mJVFe58qcUCG+pPyUyozE4oz4otKc1OJD jBIczEoivLJNQDnelMTKqtSifJiUNAeLkjjvph98IUIC6YklqdmpqQWpRTBZGQ4OJQneyC6g RsGi1PTUirTMnBKENBMHJ8hwHqDhJ0FqeIsLEnOLM9Mh8qcYFaXEeZ1BEgIgiYzSPLheWEJ5 xSgO9IowrzBIFQ8wGcF1vwIazAQ0uF0AbHBJIkJKqoFxrWvv4d9PFS4xHSj7cvBK3iqriBL1 l6WHfQ/HH5GTcN5ySmHdn1UlW9hudCiq9PGxlr2cfjX0svDq6f6MG9yMVryTufHQaGbH79yl a8753dGIDlN4mC8fNFm78k95HYuR0dPArbrnFp915RcJetJ5fMeZSkGO+JLLP6WkE9yXsq+0 lz/0+/scJZbijERDLeai4kQAsB0nygMDAAA= X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Jun 2015 16:47:58 -0000 (was Re: avoiding base openssl when building ports) On Mon, 1 Jun 2015, Kimmo Paasiala wrote: > This leads to another question. Where is the line going to be drawn > which libraries in the base system should be private? There are > certainly some of them that have to be public like libc and the > support libraries like libusb. There is certainly no sense in making > the ports system use full set of its own libraries for everything > either. [changing Subject: in the hopes of preserving Don's original thread...] Again, I am not one of the people implementing private libraries, but one potential motivation for making something private is if the support lifecycle of an upstream vendor project does not match with the support lifecycle for FreeBSD stable releases. If a library is private in FreeBSD, it is more likely to be POLA-compatible to replace it with a new upstream version mid-stable-branch than if it was a public library. Another possible motivator for making something private is if we have a library in base only for a small subset of the features it provides, and we want to prevent external consumers from trying to rely on the broader set of features in that library. This would reduce the support burden for the library in question, since bugs or vulnerabilities in the unused functionality would not be deemed critical. -Ben From owner-freebsd-security@FreeBSD.ORG Mon Jun 1 17:12:07 2015 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id C6F27479; Mon, 1 Jun 2015 17:12:07 +0000 (UTC) (envelope-from franco@lastsummer.de) Received: from host64.kissl.de (host64.kissl.de [213.239.241.64]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.shmhost.net", Issuer "COMODO RSA Domain Validation Secure Server CA" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 60E9A1E30; Mon, 1 Jun 2015 17:12:07 +0000 (UTC) (envelope-from franco@lastsummer.de) Received: from localhost (localhost.localdomain [127.0.0.1]) by host64.kissl.de (Postfix) with ESMTP id CD236B00EFE; Mon, 1 Jun 2015 19:03:59 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at host64.kissl.de Received: from host64.kissl.de ([127.0.0.1]) by localhost (host64.kissl.de [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PNKSfZle20gI; Mon, 1 Jun 2015 19:03:59 +0200 (CEST) Received: from francos-mbp.fritz.box (x4d059333.dyn.telefonica.de [77.5.147.51]) (Authenticated sender: web104p1) by host64.kissl.de (Postfix) with ESMTPSA id 7B554B00EFD; Mon, 1 Jun 2015 19:03:59 +0200 (CEST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) Subject: Re: scope of private libraries From: Franco Fichtner In-Reply-To: Date: Mon, 1 Jun 2015 19:03:59 +0200 Cc: Kimmo Paasiala , freebsd-security , Don Lewis , spil.oss@gmail.com Content-Transfer-Encoding: 7bit Message-Id: <2C5684F6-5D01-42BE-A7BD-13DD88040128@lastsummer.de> References: <201506010138.t511cp2P088983@gw.catspoiler.org> To: Benjamin Kaduk X-Mailer: Apple Mail (2.2098) X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Jun 2015 17:12:07 -0000 > On 01 Jun 2015, at 18:42, Benjamin Kaduk wrote: > > (was Re: avoiding base openssl when building ports) > > On Mon, 1 Jun 2015, Kimmo Paasiala wrote: > >> This leads to another question. Where is the line going to be drawn >> which libraries in the base system should be private? There are >> certainly some of them that have to be public like libc and the >> support libraries like libusb. There is certainly no sense in making >> the ports system use full set of its own libraries for everything >> either. > > [changing Subject: in the hopes of preserving Don's original thread...] > > Again, I am not one of the people implementing private libraries, but one > potential motivation for making something private is if the support > lifecycle of an upstream vendor project does not match with the support > lifecycle for FreeBSD stable releases. If a library is private in > FreeBSD, it is more likely to be POLA-compatible to replace it with a new > upstream version mid-stable-branch than if it was a public library. > > Another possible motivator for making something private is if we have a > library in base only for a small subset of the features it provides, and > we want to prevent external consumers from trying to rely on the broader > set of features in that library. This would reduce the support burden for > the library in question, since bugs or vulnerabilities in the unused > functionality would not be deemed critical. I like this. Why not start with OpenSSL in base and make the OpenSSL port mandatory? Still struggling with the LibreSSL integration, which is quite obscured by the base library with recent holes uncovered that also applied to OpenSSL from ports. The fallback to OpenSSL from base creates a convenience scenario that hurts (and already has hurt) security. This makes security-related ports updates faster and reduces the attack surface of the base system. Everthing is moving to pkgng anyway as far as the pkgng team is concerned. ;) As a side note, does pkgng really have to depend on base OpenSSL; does it have to depend on a full-blown SSL library? Cheers, Franco From owner-freebsd-security@FreeBSD.ORG Mon Jun 1 18:06:07 2015 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id F0D0AAB7 for ; Mon, 1 Jun 2015 18:06:06 +0000 (UTC) (envelope-from kaduk@mit.edu) Received: from dmz-mailsec-scanner-7.mit.edu (dmz-mailsec-scanner-7.mit.edu [18.7.68.36]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 9C18B1AFC for ; Mon, 1 Jun 2015 18:06:06 +0000 (UTC) (envelope-from kaduk@mit.edu) X-AuditID: 12074424-f79b06d000000cfd-be-556c9dd83f46 Received: from mailhub-auth-1.mit.edu ( [18.9.21.35]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-7.mit.edu (Symantec Messaging Gateway) with SMTP id 8B.D5.03325.8DD9C655; Mon, 1 Jun 2015 14:00:57 -0400 (EDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-1.mit.edu (8.13.8/8.9.2) with ESMTP id t51I0uZo004374; Mon, 1 Jun 2015 14:00:56 -0400 Received: from multics.mit.edu (system-low-sipb.mit.edu [18.187.2.37]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id t51I0rap021772 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 1 Jun 2015 14:00:54 -0400 Received: (from kaduk@localhost) by multics.mit.edu (8.12.9.20060308) id t51I0qte007744; Mon, 1 Jun 2015 14:00:52 -0400 (EDT) Date: Mon, 1 Jun 2015 14:00:52 -0400 (EDT) From: Benjamin Kaduk To: Franco Fichtner cc: Kimmo Paasiala , freebsd-security Subject: Re: scope of private libraries In-Reply-To: <2C5684F6-5D01-42BE-A7BD-13DD88040128@lastsummer.de> Message-ID: References: <201506010138.t511cp2P088983@gw.catspoiler.org> <2C5684F6-5D01-42BE-A7BD-13DD88040128@lastsummer.de> User-Agent: Alpine 1.10 (GSO 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrOIsWRmVeSWpSXmKPExsUixCmqrHtzbk6owYfJ7BZXZn5gsujZ9ITN Yt2BScwOzB4zPs1n8dg56y67x7p/25kDmKO4bFJSczLLUov07RK4MiYeiCto4ayY9/onawPj bbYuRk4OCQETiesnJ0LZYhIX7q0Hsrk4hAQWM0lsm3COHcLZwCixuusaC4RzkEli9892sBYh gXqJjssbWEBsFgEtiTmbzzCD2GwCKhIz32wEqxEBin/rhrCZBRIlzv69ywpiCwuoS2yf8was nlPAUWL+h7NgcV4gu+v6CWa4M24s3gaWEBXQkVi9fwoLRJGgxMmZT1gghmpJLJ++jWUCo+As JKlZSFILGJlWMcqm5Fbp5iZm5hSnJusWJyfm5aUW6Zrr5WaW6KWmlG5iBIUvu4vKDsbmQ0qH GAU4GJV4eDO6s0OFWBPLiitzDzFKcjApifIaTMoJFeJLyk+pzEgszogvKs1JLT7EKMHBrCTC K9sElONNSaysSi3Kh0lJc7AoifNu+sEXIiSQnliSmp2aWpBaBJOV4eBQkuC9OQeoUbAoNT21 Ii0zpwQhzcTBCTKcB2h4CkgNb3FBYm5xZjpE/hSjopQ47yWQhABIIqM0D64Xll5eMYoDvSLM awxSxQNMTXDdr4AGMwENbhcAG1ySiJCSamBs3HBQ2KbTR1Oxap9DczDHE9/ZwuXuHq812yWf XuuJ2GCX8yCUcfLKubZ6c8VV7Izb5vces1a2+RUQ4vC0R1HtZePT2fIfHIuC019x6v+96vmm RsR7hl7VTNlZZitfHz3ELBk44czjNdmus4VCHj/aaj7RfuNWvvdS6pHJGSus5N+1fvP3uq/E UpyRaKjFXFScCAAUZ3AICgMAAA== X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Jun 2015 18:06:07 -0000 On Mon, 1 Jun 2015, Franco Fichtner wrote: > As a side note, does pkgng really have to depend on base > OpenSSL; does it have to depend on a full-blown SSL library? Yes. -Ben (From IRC:) efnet / #bsddev / bjk 13:17 () In particular, Franco asked "does pkg really need to depend on openssl from base?" efnet / #bsddev / bjk 13:17 () To which I believe the answer is "yes", but am not authoritative efnet / #bsddev / bapt 13:48 (bapt!~bapt@ns3301091.ip-178-32-217.eu) bjk: I'm not reading but the answer is yes efnet / #bsddev / bapt 13:48 (bapt!~bapt@ns3301091.ip-178-32-217.eu) pkg needs openssl efnet / #bsddev / bapt 13:48 (bapt!~bapt@ns3301091.ip-178-32-217.eu) because of rsa keys efnet / #bsddev / bapt 13:48 (bapt!~bapt@ns3301091.ip-178-32-217.eu) because of sha256 as well efnet / #bsddev / bapt 13:48 (bapt!~bapt@ns3301091.ip-178-32-217.eu) well this one could be replaced by libmd but it is way slower efnet / #bsddev / bapt 13:49 (bapt!~bapt@ns3301091.ip-178-32-217.eu) also without openssl no https support From owner-freebsd-security@FreeBSD.ORG Mon Jun 1 21:11:26 2015 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 6EA5E9B3 for ; Mon, 1 Jun 2015 21:11:26 +0000 (UTC) (envelope-from walt.ford@yahoo.com) Received: from nm17-vm2.bullet.mail.ne1.yahoo.com (nm17-vm2.bullet.mail.ne1.yahoo.com [98.138.91.93]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 307F01B3D for ; Mon, 1 Jun 2015 21:11:25 +0000 (UTC) (envelope-from walt.ford@yahoo.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1433192674; bh=TYzSkk9CboX5TAJLMV6G45S5cIpFzeSkQdzlFB+gbRo=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From:Subject; b=SGEqQzaQ2qHdvZGoOITCCm9WolKCatjhcM3YpcRXWBgf2Cq2McdU5/3HYik0FSq2G/N9WfQhwiZmDczXVc66h+25d6qbZ/IZsLMte5aJaGVlLmNfGzduWaCkRK+1rYZzo6waqmMABBZ/YgFgNMXmo/gnGZva0u4/vWWiN47COXt03CBzEA+AWo3Gtc5AuE2K6saEe6vPXpjhFplMaAZC44kTr4ccIeRy54D7d2n58goyr0sgo3AKHiotX7OkzyeYNmlT8lj4AILSH59Zi+Bg4NmIqMzhSuHpnaNqnvLtFi/3JWmsv3o+9J0i1yI0TTjYqg6vyp+sx6TlsJBjsluPjA== Received: from [98.138.100.117] by nm17.bullet.mail.ne1.yahoo.com with NNFMP; 01 Jun 2015 21:04:34 -0000 Received: from [98.138.84.43] by tm108.bullet.mail.ne1.yahoo.com with NNFMP; 01 Jun 2015 21:04:34 -0000 Received: from [127.0.0.1] by smtp111.mail.ne1.yahoo.com with NNFMP; 01 Jun 2015 21:04:34 -0000 X-Yahoo-Newman-Id: 343538.39011.bm@smtp111.mail.ne1.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: H5RDKZwVM1kFrF7X60jWK1RAzCEgrWboKwuNh7IoWZFvFCw QesuCxB.FuzfYDOEcHaRIIcw7XWQI3AUWkd6nMdp1emoT4VScVxtKQaPsG6G .5Q3IhvdLzd2n2_wjD8DGAMKaWA_MJJ.0kcqrMCpBo98RrDT6YTCSqSAgYgT T9foHjYUP6mCpU9uGEnZkrzmaIxPt4vusXoJyXsuQuWrwuiDYRIMNf5K4G7P xhBe.zt4qSG91.B3IRCltierLlY8BQPJ6RCwt3k5.8Z6G1UmY2YzWj7Szhli 5KPYAAauiW4Q9mDzDqG4iVaHz49rXjPcPIgfaG84KQLj8ARTpgZKtmALRUMt yILxitIRICurVpzKt0uxNMrhdMzbzXKZQX62WTRsS0HzdLqSnnEauUIFWu7P _GodMkUytGedWPPskMUPRjHBJb_S6Df43KYLis9jlvmIQGabL6pIvXn_gqQC bzY6G1aZARFdwHb.FhpqeZCJI3WKFJ3v6ZqZX4Epje8R_6plIWPXM2g-- X-Yahoo-SMTP: yVvIDoOswBD5zOzqXnwUE.yVSR2Kvw-- Date: Mon, 1 Jun 2015 17:05:20 -0400 From: Walt Ford To: Julian Elischer Cc: freebsd-security@freebsd.org Subject: Re: avoiding base openssl when building ports Message-ID: <20150601210520.GE68495@ws1> References: <201506010138.t511cp2P088983@gw.catspoiler.org> <556C8BFE.708@freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <556C8BFE.708@freebsd.org> User-Agent: Mutt/1.5.23 (2014-03-12) X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Jun 2015 21:11:26 -0000 On Tue, Jun 02, 2015 at 12:44:46AM +0800, Julian Elischer wrote: > I'd like to take a bunch of libraries out of base, But That is not the > same as making them "ports". > I've said before that I thik we need something half way between. using > the ports/pkg mechanism, You could just call them supported ports. Supported means what currently happens with 3rd party code in base, and unsupported is what software in ports currently is. But, seems like there still would be an issue with compatibility and a stable API or ABI. If the current restrictions are going away, then you might as well just make them ports. If they're staying, you'll end up with an outdated supported port being maintained separately from the current unsupported port, just like now essentially. -- Skip From owner-freebsd-security@FreeBSD.ORG Mon Jun 1 23:46:57 2015 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 74B83C57 for ; Mon, 1 Jun 2015 23:46:57 +0000 (UTC) (envelope-from venture37@gmail.com) Received: from mail-wi0-x22d.google.com (mail-wi0-x22d.google.com [IPv6:2a00:1450:400c:c05::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 201D71067 for ; Mon, 1 Jun 2015 23:46:57 +0000 (UTC) (envelope-from venture37@gmail.com) Received: by wifw1 with SMTP id w1so124234751wif.0 for ; Mon, 01 Jun 2015 16:46:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=U1kJ7FAQVQt/9LKS7xE/D0P1uRDuvkOE+yO+i5Qu0qk=; b=pgU6rh60cxaPL8dBYInE6FuXKf3KIaZd2w/AANtIyPmSOWS1P9W5IisaQZTGqVgvWP biyUUBUYUT1hsB1TBEjoeBQFSOXmPXNF9JYCJymoO+jcS+bKxIUGHJjUU0ZjJtpSeUFh 8uevi3LzCO51+H/O4FeN8vQRz0du15lHuhDJnGYO/33dEGZpj/E47TRUTh8eXAqauGXn icc419HmseSpMroVklVl6Tn0x6zFCUE90nQ4r99UBMh3pxcGvaTqNNN+bE11eFkiaLU0 DXRfgK8a7aPOah0+lEAaSzsjhQhRWW97w9F0ut+/3kDDFyP8iHhRuucMwjLF8YjHkzVV AuFQ== MIME-Version: 1.0 X-Received: by 10.180.92.162 with SMTP id cn2mr25546691wib.26.1433202415388; Mon, 01 Jun 2015 16:46:55 -0700 (PDT) Received: by 10.194.88.165 with HTTP; Mon, 1 Jun 2015 16:46:55 -0700 (PDT) In-Reply-To: <1430250480.672566.259824585.439C7F0B@webmail.messagingengine.com> References: <553DF49E.3020502@riseup.net> <1430250480.672566.259824585.439C7F0B@webmail.messagingengine.com> Date: Tue, 2 Jun 2015 00:46:55 +0100 Message-ID: Subject: Re: base/release/10.1.0/contrib/file vulnerabilities? From: "Sevan / Venture37" To: freebsd-security@freebsd.org Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Jun 2015 23:46:57 -0000 On 28 April 2015 at 20:48, Mark Felder wrote: > > > On Mon, Apr 27, 2015, at 03:34, Piotr Kubaj wrote: >> Hi, >> >> I wrote about this vulnerability in January: >> https://lists.freebsd.org/pipermail/freebsd-security/2015-January/008115.html >> >> There were only patches for stable. >> > > There is an open PR as well > > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=198912 Update from delphij@ https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=198912#c3 Sevan / Venture37 From owner-freebsd-security@FreeBSD.ORG Tue Jun 2 14:43:11 2015 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 0F63E818 for ; Tue, 2 Jun 2015 14:43:11 +0000 (UTC) (envelope-from franco@lastsummer.de) Received: from host64.kissl.de (host64.kissl.de [213.239.241.64]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.shmhost.net", Issuer "COMODO RSA Domain Validation Secure Server CA" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id BE84619E0 for ; Tue, 2 Jun 2015 14:43:10 +0000 (UTC) (envelope-from franco@lastsummer.de) Received: from localhost (localhost.localdomain [127.0.0.1]) by host64.kissl.de (Postfix) with ESMTP id 1FF91B00EF3; Tue, 2 Jun 2015 16:43:08 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at host64.kissl.de Received: from host64.kissl.de ([127.0.0.1]) by localhost (host64.kissl.de [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oL8E9cyHBWO1; Tue, 2 Jun 2015 16:43:08 +0200 (CEST) Received: from francos-mbp.fritz.box (x4d01c52f.dyn.telefonica.de [77.1.197.47]) (Authenticated sender: web104p1) by host64.kissl.de (Postfix) with ESMTPSA id D1D0FB00EF2; Tue, 2 Jun 2015 16:43:07 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) Subject: Re: scope of private libraries From: Franco Fichtner In-Reply-To: Date: Tue, 2 Jun 2015 16:43:07 +0200 Cc: Kimmo Paasiala , freebsd-security Content-Transfer-Encoding: quoted-printable Message-Id: <936D98CC-EC18-4274-B79D-13320CD398D5@lastsummer.de> References: <201506010138.t511cp2P088983@gw.catspoiler.org> <2C5684F6-5D01-42BE-A7BD-13DD88040128@lastsummer.de> To: Benjamin Kaduk X-Mailer: Apple Mail (2.2098) X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Jun 2015 14:43:11 -0000 Hi, the general lack of responses is probably why we have the OpenSSL base issues and maybe they won=E2=80=99t go away anytime soon, even though there are no downsides to modularisation. Yes, anyone can submit patches, but how can potential contributors from the security domain bring in patches that elude the scope of the FreeBSD developers. How can we reason for better security under such circumstances? How can a widespread adoption of the diversity trend of crypto libraries be embraced by FreeBSD without stepping on anyone=E2=80=99s toes? How do we actually create the necessary awareness? How can we move from labels of =E2=80=9Cparanoid=E2=80=9D to =E2=80=9Csecure=E2=80=9D? The last time I tried WITHOUT_CRYPT=3D1 it was dysfunctional despite the fact that the flag exists for the purpose of decoupling base from crypto and being documented without the notion of having =E2=80=9Chiccups=E2=80=9D. And now even one dependency from the ports is what can prolong said status quo in the face of a constant stream of upcoming security advisories. > On 01 Jun 2015, at 20:00, Benjamin Kaduk wrote: >=20 > On Mon, 1 Jun 2015, Franco Fichtner wrote: >=20 >> As a side note, does pkgng really have to depend on base >> OpenSSL; does it have to depend on a full-blown SSL library? >=20 > Yes. Thanks for the quick answer from the source, Benjamin. It is, however, not a good reason why pkgng is dynamically linked to OpenSSL in base when e.g. sqlite and libucl are embedded to avoid chicken and egg issues. Why should OpenSSL be the exception? Because it is in base? Because it is too big? Wouldn=E2=80=99t it be easier to embed and deal with security issues through the ports/packages infrastructure which basically rocks? FreeBSD should put effort into getting there, eventually. That=E2=80=99s all I=E2=80=99m saying. Where do we start then? Cheers, Franco= From owner-freebsd-security@FreeBSD.ORG Tue Jun 2 14:50:07 2015 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 60F8DBD6 for ; Tue, 2 Jun 2015 14:50:07 +0000 (UTC) (envelope-from kpaasial@gmail.com) Received: from mail-la0-x234.google.com (mail-la0-x234.google.com [IPv6:2a00:1450:4010:c03::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id D2E251A92 for ; Tue, 2 Jun 2015 14:50:06 +0000 (UTC) (envelope-from kpaasial@gmail.com) Received: by laei3 with SMTP id i3so39634082lae.3 for ; Tue, 02 Jun 2015 07:50:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=Dc1XzbEUSlZ9xyVr4/67SlvReWtZNMfGoEqFuQ+SYPk=; b=qrRjVM6r/Dsst1XHt3b0vXSZ/0t712RhC0YN7e5Do2hoMnMZ23p9iOeHE2NNGummQz dXPqNDEw7gpvhEmyI8BqseKqBoRg+PyaaATKEtNMIO9lavcVVZSMCWCV4FQPQLaYHoR4 xB2EdHByVJRer/C8ioW3WtqdqzkIS/pcSD/zNV41xgcgIXWvL+c7LQoTmHVXse5akypQ B/mciGEOafFDVXrw/RXTghlUSWpPp7hS85hzALklMtyP6StYV6bXw/TovOaBo0UH6Ehv 2xsfoxvClY8dWhTzLCRagQz/hcwSEXn6QVdh+wQPJaX1G4x5oilsS2WdOadDbFulStsg HDvg== MIME-Version: 1.0 X-Received: by 10.152.203.162 with SMTP id kr2mr26704651lac.68.1433256603791; Tue, 02 Jun 2015 07:50:03 -0700 (PDT) Received: by 10.152.137.193 with HTTP; Tue, 2 Jun 2015 07:50:03 -0700 (PDT) In-Reply-To: <936D98CC-EC18-4274-B79D-13320CD398D5@lastsummer.de> References: <201506010138.t511cp2P088983@gw.catspoiler.org> <2C5684F6-5D01-42BE-A7BD-13DD88040128@lastsummer.de> <936D98CC-EC18-4274-B79D-13320CD398D5@lastsummer.de> Date: Tue, 2 Jun 2015 17:50:03 +0300 Message-ID: Subject: Re: scope of private libraries From: Kimmo Paasiala To: Franco Fichtner Cc: Benjamin Kaduk , freebsd-security Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Jun 2015 14:50:07 -0000 On Tue, Jun 2, 2015 at 5:43 PM, Franco Fichtner wrot= e: > Hi, > > the general lack of responses is probably why we have the > OpenSSL base issues and maybe they won=E2=80=99t go away anytime > soon, even though there are no downsides to modularisation. > > Yes, anyone can submit patches, but how can potential > contributors from the security domain bring in patches > that elude the scope of the FreeBSD developers. How can > we reason for better security under such circumstances? > How can a widespread adoption of the diversity trend of > crypto libraries be embraced by FreeBSD without stepping > on anyone=E2=80=99s toes? How do we actually create the necessary > awareness? How can we move from labels of =E2=80=9Cparanoid=E2=80=9D to > =E2=80=9Csecure=E2=80=9D? > > The last time I tried WITHOUT_CRYPT=3D1 it was dysfunctional > despite the fact that the flag exists for the purpose of > decoupling base from crypto and being documented without > the notion of having =E2=80=9Chiccups=E2=80=9D. > > And now even one dependency from the ports is what can > prolong said status quo in the face of a constant stream > of upcoming security advisories. > >> On 01 Jun 2015, at 20:00, Benjamin Kaduk wrote: >> >> On Mon, 1 Jun 2015, Franco Fichtner wrote: >> >>> As a side note, does pkgng really have to depend on base >>> OpenSSL; does it have to depend on a full-blown SSL library? >> >> Yes. > > Thanks for the quick answer from the source, Benjamin. > > It is, however, not a good reason why pkgng is dynamically > linked to OpenSSL in base when e.g. sqlite and libucl are > embedded to avoid chicken and egg issues. Why should OpenSSL > be the exception? Because it is in base? Because it is too > big? Wouldn=E2=80=99t it be easier to embed and deal with security > issues through the ports/packages infrastructure which > basically rocks? > > FreeBSD should put effort into getting there, eventually. > That=E2=80=99s all I=E2=80=99m saying. Where do we start then? > > > Cheers, > Franco Even if the base system OpenSSL was modularized using pkg it would be still subject to ABI stability requirements. In other words it would be stuck at the version or versions that are 100% ABI compatible with one installed initially on the first minor version of the same major version line. Only critical security fixes would be backported to it exactly as it is done now with the base system OpenSSL. -Kimmo From owner-freebsd-security@FreeBSD.ORG Tue Jun 2 15:16:58 2015 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 739C2972 for ; Tue, 2 Jun 2015 15:16:58 +0000 (UTC) (envelope-from franco@lastsummer.de) Received: from host64.kissl.de (host64.kissl.de [213.239.241.64]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.shmhost.net", Issuer "COMODO RSA Domain Validation Secure Server CA" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 2D38E128D for ; Tue, 2 Jun 2015 15:16:57 +0000 (UTC) (envelope-from franco@lastsummer.de) Received: from localhost (localhost.localdomain [127.0.0.1]) by host64.kissl.de (Postfix) with ESMTP id 5CA2BB00F02; Tue, 2 Jun 2015 17:16:56 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at host64.kissl.de Received: from host64.kissl.de ([127.0.0.1]) by localhost (host64.kissl.de [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dN76U5PVn+xT; Tue, 2 Jun 2015 17:16:56 +0200 (CEST) Received: from francos-mbp.fritz.box (x4d01c52f.dyn.telefonica.de [77.1.197.47]) (Authenticated sender: web104p1) by host64.kissl.de (Postfix) with ESMTPSA id 1F88CB00F01; Tue, 2 Jun 2015 17:16:56 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) Subject: Re: scope of private libraries From: Franco Fichtner In-Reply-To: Date: Tue, 2 Jun 2015 17:16:55 +0200 Cc: Benjamin Kaduk , freebsd-security Content-Transfer-Encoding: quoted-printable Message-Id: <7C328F06-A37A-4A1D-922E-A077FBABA306@lastsummer.de> References: <201506010138.t511cp2P088983@gw.catspoiler.org> <2C5684F6-5D01-42BE-A7BD-13DD88040128@lastsummer.de> <936D98CC-EC18-4274-B79D-13320CD398D5@lastsummer.de> To: Kimmo Paasiala X-Mailer: Apple Mail (2.2098) X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Jun 2015 15:16:58 -0000 > On 02 Jun 2015, at 16:50, Kimmo Paasiala wrote: >=20 > Even if the base system OpenSSL was modularized using pkg it would be > still subject to ABI stability requirements. In other words it would > be stuck at the version or versions that are 100% ABI compatible with > one installed initially on the first minor version of the same major > version line. Only critical security fixes would be backported to it > exactly as it is done now with the base system OpenSSL. OpenSSL base is only used by base, unexposed. All ports are built against OpenSSL from ports. I don=E2=80=99t see the ABI problem. pkgng takes care of updating shared library dependencies and ABI changes. We can already move OPNsense installations from OpenSSL to LibreSSL and back without a flinch. The real issue are hand-rolled production systems that rely on a stable crypto API because someone did not want to add a ports/packages workflow to implement proper dependency tracking. I don=E2=80=99t think = that has worked out particularly well. ;) Cheers, Franco= From owner-freebsd-security@FreeBSD.ORG Tue Jun 2 15:17:38 2015 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 35B18ADB; Tue, 2 Jun 2015 15:17:38 +0000 (UTC) (envelope-from bdrewery@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 1542712EF; Tue, 2 Jun 2015 15:17:38 +0000 (UTC) (envelope-from bdrewery@FreeBSD.org) Received: from mail.xzibition.com (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.9/8.14.9) with ESMTP id t52FHb64011968; Tue, 2 Jun 2015 15:17:37 GMT (envelope-from bdrewery@FreeBSD.org) Received: from mail.xzibition.com (localhost [172.31.3.2]) by mail.xzibition.com (Postfix) with ESMTP id 74D4586B1; Tue, 2 Jun 2015 15:17:37 +0000 (UTC) X-Virus-Scanned: amavisd-new at mail.xzibition.com Received: from mail.xzibition.com ([172.31.3.2]) by mail.xzibition.com (mail.xzibition.com [172.31.3.2]) (amavisd-new, port 10026) with LMTP id FP1WRmT8nE5t; Tue, 2 Jun 2015 15:17:37 +0000 (UTC) Message-ID: <556DC912.1060808@FreeBSD.org> DKIM-Filter: OpenDKIM Filter v2.9.2 mail.xzibition.com 85C1286AE Date: Tue, 02 Jun 2015 10:17:38 -0500 From: Bryan Drewery Organization: FreeBSD User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Kimmo Paasiala , Benjamin Kaduk CC: freebsd-security , Don Lewis Subject: Re: avoiding base openssl when building ports References: <201506010138.t511cp2P088983@gw.catspoiler.org> In-Reply-To: OpenPGP: id=F9173CB2C3AAEA7A5C8A1F0935D771BB6E4697CF; url=http://www.shatow.net/bryan/bryan2.asc Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="A14iunkffbF9ccacKIouEgWGdcimtBGxT" X-Mailman-Approved-At: Tue, 02 Jun 2015 15:18:59 +0000 X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Jun 2015 15:17:38 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --A14iunkffbF9ccacKIouEgWGdcimtBGxT Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On 6/1/2015 11:25 AM, Kimmo Paasiala wrote: > On Mon, Jun 1, 2015 at 7:17 PM, Benjamin Kaduk wrote: >> On Sun, 31 May 2015, Don Lewis wrote: >> >>> The big culprit turned out to be ftp/curl. Even though >>> WITH_OPENSSL_PORT=3Dyes caused it to add the openssl port as a build = and >>> run dependency, it was silently getting linked to openssl from base. = The >>> cause of that problem is that the default GSSAPI_BASE option adds >>> -L/usr/lib near the start of LDFLAGS, so the linker finds the base >>> openssl libraries instead of the ones from the port. I worked around= >>> that problem by switching to GSSAPI_NONE, though I tested that the ot= her >>> GSSAPI_* options also work correctly. There is a sanity check in the= >>> Makefile that attempts to catch this conflict, but it does not work >>> correctly. See >>> . >> >> My apologies for semi-hijacking your thread, but I am starting to wond= er >> whether the base Heimdal (and GSSAPI) should be converted to be a priv= ate >> library. Since I am living in a MIT krb5 world, which is incompatible= >> with the Heimdal libraries, I end up having some trouble trying to for= ce >> various things to be used from base vs. ports. >> >> Making the Heimdal in base into private libraries would "solve" the >> problem with ftp/curl, but only insamuch as it would make the GSSAPI_B= ASE >> option useless and require a GSSAPI from ports. >> >> -Ben >=20 >=20 > Rumour is that something like that is going to happen with all of the > problematic libraries by making them private. If someone with inside > knowledge could confirm these rumours? ;) I don't know why you call this a rumor. It's an ongoing effort for over a year now. It's just been slow due to lack of consensus and other technical and social issues. It's not that we try to keep things secret here, it's just that we tend to discuss on IRC and then if the issue is big enough discuss it on arch@ or just use a phabricator review. If it is trivial and there is no concern of problems then it is just committed. It's simply not practical to discuss everything in email. Usually we get an itch to make a library private and discuss it quickly in a private message and then produce a patch. >=20 > This leads to another question. Where is the line going to be drawn > which libraries in the base system should be private? There are > certainly some of them that have to be public like libc and the > support libraries like libusb. There is certainly no sense in making > the ports system use full set of its own libraries for everything > either. Everything we do is wrong. Obviously we can't make libc private. In the current scheme only 3rd party libraries or libraries that are only needed for internal build tools or libraries which are constant security concerns are really eligible for becoming private libs. In a correct world everything in the base system would be a "package" in the same sense as ports has "packages". Libc too would be a "package". We would have 1 and only 1 OpenSSL "package" rather than a private one and port one. When this discussion comes up people tend to jump to the wrong conclusions. This is not suggesting making the base system only a kernel and "good luck go run pkg". It's just saying everything would be packaged and most likely due to POLA be the same installed files we provide today in the base world system. Our base system and ports system frameworks are severely lacking to make this all possible today though. We also have social hurdles. The way we're doing private libs now is flawed as is since it easily leaks these private libs into the public linker space. For example, if we made OpenSSL private in the base then libfetch would be providing OpenSSL private lib links when libfetch was linked in. This defeats the purpose of having OpenSSL as private and can cause collisions. Regards, Bryan Drewery --A14iunkffbF9ccacKIouEgWGdcimtBGxT Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAEBAgAGBQJVbckSAAoJEDXXcbtuRpfP5BAH/jfnfsSaHFXR2MJTP0pgke4O GiOlcdq3ioyG9gVsf9fXZZaYn/7J9//r+hb/v6FlnWYsOIc4/ylGPAkENXuBVN7d 8nhKUai9OYGllGZ9umOPm44gLysFkBm1wGfpOY6FkeEx3yQNOQzmB9Jb4o7EdtZ7 pKxvcrVDQ32Osz7xufp8/lbYXrS8caWoLmbOfIdCnrLZHrxmUhYznpLQi2BIQ/pp 7HcvV5bxitE5I+HnBHCccSLHsPu8yw+JpwOd+brYCWoFuCgrCaDfpUY7wCPDHtj0 fJAcYSNC28X2O0uMbkYV2dPqxs0B/e2iebP5PGdgpuliXMXxmqDrbbHQFhgthpw= =0pY4 -----END PGP SIGNATURE----- --A14iunkffbF9ccacKIouEgWGdcimtBGxT-- From owner-freebsd-security@FreeBSD.ORG Tue Jun 2 17:32:32 2015 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 8A8A152B for ; Tue, 2 Jun 2015 17:32:32 +0000 (UTC) (envelope-from jeffreybouquet@yahoo.com) Received: from nm16.bullet.mail.bf1.yahoo.com (nm16.bullet.mail.bf1.yahoo.com [98.139.212.175]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 2D68C1AAE for ; Tue, 2 Jun 2015 17:32:32 +0000 (UTC) (envelope-from jeffreybouquet@yahoo.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1433266350; bh=bsqswJav+wpnrOF6dRHBekJ+TdFhA/u6aNGjv3gGyjU=; h=Date:From:To:Subject:From:Subject; b=IdqZLSnfnuO1dTtY6g7UAVsF5l+K2TOvqSa+OYdDAZyg8W8kM4u/cCDDYbbKzB8lbMpSy5hkiBuoOJu1BdSLORwd587rumqbaXVEPtPu57XnUqxZF7wuwjRMsvR5Z22WIScsa1Y1TYwo9gZ4N6wa4LA7U4/kh7T+mNB/kzbGkqqbdY7GQF9x3+eucOqWt14MI1R50EDDuJAZhJccuhP12oQNorUrn1IByGDMpEBJoVnTk4aoWl/IAWluxsVIt0DuyTTf2N+nJDMidVNdN7NMq90Ib2TstHsNvD4JlLoU4o98p53otAr5Y2UlX8wXWQY3LpG9UgMYaQcJn7fUH2hx/g== Received: from [98.139.215.141] by nm16.bullet.mail.bf1.yahoo.com with NNFMP; 02 Jun 2015 17:32:30 -0000 Received: from [98.139.213.14] by tm12.bullet.mail.bf1.yahoo.com with NNFMP; 02 Jun 2015 17:32:30 -0000 Received: from [127.0.0.1] by smtp114.mail.bf1.yahoo.com with NNFMP; 02 Jun 2015 17:32:30 -0000 X-Yahoo-Newman-Id: 195503.63190.bm@smtp114.mail.bf1.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: WWM6e7IVM1nlRyEuBhIe3V.VtC5Qn05SGI7exdL.FYxKRhj WdD5V80ISC8A8jQ2gdYAuzL.5f4lIEJBKpkG2uZf0soXEgbOilmyvVuLoenS o7jB.UQ0.Z5fZ3K1z6St5q7J6IQOuqQbM8OzO2ZQFxEtSIKUx368ipUpbsi2 PVbanWUYbI4jKUeDAlpj3ywT_tFqKhtJs3_onvW0SYi9gUwPorrdiJKZmzPp zD6Sl.x2eFxN3hwWAznc3X_N6RkN7sqwKJW98r_kRkIR79u.ptHBnvyAgCuz x3pi7O79vQytasUsJAmNGgFprX1PD5jVm9kyZSiTmdlfmQ.kKU.blOVaQy0y vxML114myfKv.827odb__xCXZuJS881CKL4lIEB.brMU93DXzODUvOqvFuKG r0dtupUH1Ta0pCUXACielLxyGGeLncjzbyQqBYh2oNLtaT52yvSazo6EV3Wt ekdEu7mmU.YsBDglcxb8QYc._hN8xByusPdSRTjsowylqSXmL2tPamX692ac TM74qVSHY2gRJksrHcZGGHnuhwfPArgMFyr5u X-Yahoo-SMTP: 6IZaPQyswBAeyzp3urHRlQfBxGxx4Js3YAIn Message-ID: <556DE863.2030108@yahoo.com> Date: Tue, 02 Jun 2015 10:31:15 -0700 From: Jeffrey Bouquet User-Agent: Mozilla/5.0 (X11; FreeBSD i386; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: freebsd-security@freebsd.org, freebsd-pkg@freebsd.org Subject: RE: avoiding base openssl when building ports [security@freebsd thread] Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Tue, 02 Jun 2015 17:51:41 +0000 X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Jun 2015 17:32:32 -0000 I see a need for the following scenario *before* switching around libraries: [ based on failure of 'pkg' to continue working across a major release without tweaks ] pkg pre-major-upgrade * convert local.sqlite to /var/db/pkg legacy format * build a temporary copy of legacy pkg_install perform upgrade make -DWHICH_IS_STILL_WORKING installworld then, if 'pkg' and its libraries break something, maybe the legacy tools can fix it up, pkg2ng made more robust [ I've never had it work fully on a v9 ] then pkg2ng >> pkg working again after the upgrade more less-likely-to-fail, as it were, say for a production system, buying some time to reinstall or whatever... say devel/ncurses breaks a production system, maybe pkg_install ncurses would work where "make build" would fail "fail to register package... cannot build something depeding upon it without the temporary pkg_install >> portmaster... Lots of coding, though... a ' temportary dual-method package system, HAST-like...' almost exclusively for major version upgrades... [ Reminded of by one of the posts in the thread... cannot quote it directly within this discussion, maybe, may make it less clear, because I am not versed enough in the workings of the base and system libraries... nor "make distribution" etc... ] From owner-freebsd-security@FreeBSD.ORG Sat Jun 6 19:48:20 2015 Return-Path: Delivered-To: freebsd-security@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id B2CACA3C; Sat, 6 Jun 2015 19:48:20 +0000 (UTC) (envelope-from Daniel@Plominski.eu) Received: from root1-rz1-hetzner.plitc.eu (root1-rz1-hetzner.plitc.eu [IPv6:2a01:4f8:a0:4283::10]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "root1-rz1-hetzner.plitc.eu", Issuer "StartCom Class 2 Primary Intermediate Server CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 7441313D7; Sat, 6 Jun 2015 19:48:19 +0000 (UTC) (envelope-from Daniel@Plominski.eu) Received: from localhost (localhost [127.0.0.1]) by root1-rz1-hetzner.plitc.eu (Postfix) with ESMTP id D477BAE0076; Sat, 6 Jun 2015 21:48:17 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at root1-rz1-hetzner.plitc.eu Received: from root1-rz1-hetzner.plitc.eu ([127.0.0.1]) by localhost (root1-rz1-hetzner.plitc.eu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CdVMWP7R8E7V; Sat, 6 Jun 2015 21:48:17 +0200 (CEST) Received: from MacBook1-PLITC.local (unknown [46.246.49.182]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: daniel@plominski.eu) by root1-rz1-hetzner.plitc.eu (Postfix) with ESMTPSA id B9147AE0074; Sat, 6 Jun 2015 21:48:16 +0200 (CEST) Message-ID: <55734E7F.2070308@Plominski.eu> Date: Sat, 06 Jun 2015 21:48:15 +0200 From: "Daniel DP. Plominski" MIME-Version: 1.0 To: freebsd-net@FreeBSD.org, freebsd-security@FreeBSD.org Subject: IPsec-Tools 0-Day Denial of Service Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Jun 2015 19:48:20 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 https://www.altsci.com/ipsec/ipsec-tools-sa.html security/ipsec-tools build with gssapi: CRASHED (FreeBSD 10.1 + ipsec-tools 0.8.2_1) best regards Daniel -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJVc05/AAoJEHqkZNWiQao7tIIP/1A+EdQNylO3kLeO+LZA3j+7 U5BSq9lmCHVmNhiGcb0Q7u2px/t60p5axbuJbJLGAOGFsbeFy+nXCjXvgc4BI7Xq xC4QR+dFy16F4w+ZVBpmOlu7+jcgHz2m2/Nq5iupUsWTmNWIEOrw1cH6Qv872eC1 mrJgaAMPHpmlY/pvrdhCkAtoGoVJztywbW7l0BYeV4lLhbOm3JtmySJ+H0zUuBFI kpG9dx3wXD8fShac/9i1mjtl3Qo8741744REHyMO7XuykroFEllsDkeYC0xwbLD0 /yj6Q+F1wQ1vZvu4XnuoxsxR18Ov1EtVJp7expfI3DC61A4yO/kr+ROGv7yhtPMl pJIsvMwqMs84+m11lalhNPd08L1dSYBBT2xF2tFUGHlhuiX7m0+jiF7a9l/M4AeY TvBqkEKVbbBWiVYr0Dd1q2R2ca5/LUq2v1MEQUmAj/c9KKWYML9VRRO0Vm94ADV8 FeywmhpPBqst9VJQ29QuOdC1z8/82sQIA1JE9e1x1Ct877fugLOEc3CJpR73lv+l l3sdJBGPE5thEELboB+F5zS29Yl/TK2YKT/WdrV8rcYOXhsHKV2Zq4/FQ9mJe+jB PukIaNiRbsfZ0R2W1mhKYg5J9ZeR5GVbsR9GulYQTxIu9grqpT+EQkVnJWusql3p 1jxrMWuBtkcEUEZ5X7/i =5y6s -----END PGP SIGNATURE----- From owner-freebsd-security@FreeBSD.ORG Sat Jun 6 19:46:49 2015 Return-Path: Delivered-To: freebsd-security@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id E9E45869; Sat, 6 Jun 2015 19:46:49 +0000 (UTC) (envelope-from service@plitc.eu) Received: from root1-rz1-hetzner.plitc.eu (root1-rz1-hetzner.plitc.eu [IPv6:2a01:4f8:a0:4283::10]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "root1-rz1-hetzner.plitc.eu", Issuer "StartCom Class 2 Primary Intermediate Server CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id AA52313BC; Sat, 6 Jun 2015 19:46:49 +0000 (UTC) (envelope-from service@plitc.eu) Received: from localhost (localhost [127.0.0.1]) by root1-rz1-hetzner.plitc.eu (Postfix) with ESMTP id 3D9BCAE0076; Sat, 6 Jun 2015 21:46:44 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at root1-rz1-hetzner.plitc.eu Received: from root1-rz1-hetzner.plitc.eu ([127.0.0.1]) by localhost (root1-rz1-hetzner.plitc.eu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RjKYVqnnD2SL; Sat, 6 Jun 2015 21:46:40 +0200 (CEST) Received: from MacBook1-PLITC.local (unknown [46.246.49.182]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: service@plitc.eu) by root1-rz1-hetzner.plitc.eu (Postfix) with ESMTPSA id B6124AE0074; Sat, 6 Jun 2015 21:46:39 +0200 (CEST) Message-ID: <55734E1E.9050500@plitc.eu> Date: Sat, 06 Jun 2015 21:46:38 +0200 From: PLITC Service MIME-Version: 1.0 To: freebsd-net@FreeBSD.org, freebsd-security@FreeBSD.org Subject: IPsec-Tools 0-Day Denial of Service Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Sat, 06 Jun 2015 22:36:28 +0000 X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Jun 2015 19:46:50 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 https://www.altsci.com/ipsec/ipsec-tools-sa.html security/ipsec-tools build with gssapi: CRASHED (FreeBSD 10.1 + ipsec-tools 0.8.2_1) best regards Daniel -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJVc04dAAoJEFjRCSf16qPCAnsP/R237p8lFV4VB8GG1r3Td3SN 0BIsQvaEHXmoBuU5RydZo02sxXkjeMzq1lu52twtEAx/DLMSy4Bv9m+bjAJ3vIGB rJ/lDq+bp4KcUcz4rO7/coivbdHJ6TVP5+/hWAOOWZqYhm3am7n2TOXI+E5gvuLy UleDufie1soJyBpSjoq2r0psPhTTt+s7NlW0JvJyDsr5QID40UpxIjrIlPX8GfzS fIBA4v8kixQCv6b+fFO1hl78O02SF1w/Zl0KIXG1Cc948vi2lZ8y0NT6YIcNLx0H pfg7OdN4J8YF8JMhG5ZMlUeVIbTDCsQLoSteB/u9WF/Gm0U2Xz/uV6WjD2br+KQh tpnfm3JYMO2xs8YSXJW7KMmp/3gEQZf/15rpTKmkQxWw6edFl43xf97wuKY4pI5P uy0LgFjkrmxEK3ifDnJlMBY/wsgGU8AngwbvOaGLy+esWQN12NDNJEpSC9Zc8Ym6 iz7QA8zXiyAlq087xcYYu0Rk/uhXwMev4N3V0CQfamhKtndORZmtZUP+i4IVihJL UAhX5x74GiQqV0vnTZpdC1IiukhSy2C/8GSXeevRrpH7XWvtTKKH5iLtbC8bBYdU btqQQM7s+dLaZQhkVamhN4rCocgQVRgS6TemjF/uzIDQaHgxgzVkZdSQHELOxMF5 bnt18bGUAsHp35Fe+SrT =PDd9 -----END PGP SIGNATURE-----