From owner-freebsd-ports@freebsd.org Sat Jul 2 14:12:44 2016 Return-Path: Delivered-To: freebsd-ports@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 7EDC3B8F169 for ; Sat, 2 Jul 2016 14:12:44 +0000 (UTC) (envelope-from matthew@FreeBSD.org) Received: from smtp.infracaninophile.co.uk (smtp.infracaninophile.co.uk [81.2.117.100]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "smtp.infracaninophile.co.uk", Issuer "infracaninophile.co.uk" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 0585A2D75 for ; Sat, 2 Jul 2016 14:12:43 +0000 (UTC) (envelope-from matthew@FreeBSD.org) Received: from liminal.local (liminal.infracaninophile.co.uk [IPv6:2001:8b0:151:1:3636:3bff:fed4:b0d6]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: m.seaman@infracaninophile.co.uk) by smtp.infracaninophile.co.uk (Postfix) with ESMTPSA id 0C00294CD for ; Sat, 2 Jul 2016 14:12:39 +0000 (UTC) Authentication-Results: smtp.infracaninophile.co.uk; dmarc=none header.from=FreeBSD.org Authentication-Results: smtp.infracaninophile.co.uk/0C00294CD; dkim=none; dkim-atps=neutral Subject: Re: what to do when base openssl isn't suitable To: freebsd-ports@freebsd.org References: <201607020225.u622Pfbc094491@gw.catspoiler.org> From: Matthew Seaman Message-ID: <6636d981-cd94-f195-8921-9792f45bef9b@FreeBSD.org> Date: Sat, 2 Jul 2016 15:12:32 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.1.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="6BJ5OeDkLwdaXBx6vrCI6ooLkukiUGgDP" X-Virus-Scanned: clamav-milter 0.99.2 at smtp.infracaninophile.co.uk X-Virus-Status: Clean X-Spam-Status: No, score=-1.2 required=5.0 tests=BAYES_00,SPF_SOFTFAIL autolearn=no autolearn_force=no version=3.4.1 X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on smtp.infracaninophile.co.uk X-BeenThere: freebsd-ports@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Porting software to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 Jul 2016 14:12:44 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --6BJ5OeDkLwdaXBx6vrCI6ooLkukiUGgDP Content-Type: multipart/mixed; boundary="3iGff33dd0OQu2gQRV0x72Gupe5E7iUk3" From: Matthew Seaman To: freebsd-ports@freebsd.org Message-ID: <6636d981-cd94-f195-8921-9792f45bef9b@FreeBSD.org> Subject: Re: what to do when base openssl isn't suitable References: <201607020225.u622Pfbc094491@gw.catspoiler.org> In-Reply-To: --3iGff33dd0OQu2gQRV0x72Gupe5E7iUk3 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On 02/07/2016 11:45, Gerard Seibert wrote: > I have to admit that this whole discussion has gotten me confused. I > use "openssl" from ports, always have and probably always will. I use > to use the now apparently depreciate statement in the /etc/make.conf > file: >=20 > WITH_OPENSSL_PORT=3DYES >=20 > From what I am reading, I would replace that line with the following > statement: >=20 > DEFAULT_VERSIONS+=3D ssl=3Dopenssl >=20 > to force the use of the "ports" version of "openssl". Is that correct, > or is my interpretation of this incorrect? These would work for an individual user to customize things via their /etc/make.conf file, and have the effect of causing all OpenSSL using ports to link against the ports version of OpenSSL. Except that neither of these constructs is valid for adding to a port's own Makefile -- and indeed, as you say, WITH_OPENSSL_PORT is no longer useable anywhere. USES=3Dssl unfortunately does not offer any argument to allow the port maintainer to limit what SSL library the user can select. There are two possible answers to this problem 1) Test the value of eg. OPENSSL_PORT after USES=3Dssl has been processed and error out if the user has chosen something incompatible with this port. 2) Make this port, and in fact all ports, compatible with as many as possible of the different variations on SSL libraries that the ports supports[*]. While (1) is superficially attractive, it basically means that your port is going to fragile in the face of changes to whichever SSL library is chosen: something that is likely to happen with different versions of FreeBSD or based on revealed security problems with these libraries. Not recommended. Essentially, you will need to be able to do (2) -- compile successfully against a number of different SSL library implementations. This is clearly much harder to do than (1), given that software consumers of SSL libraries will all have their own ideas about how to configure and link themselves, but on the whole there will be several groups of relatively similar solutions, likely one of which will be relevant and fairly easy to copy and adapt to the needs of a specific port. A lot of this work has already been done, and documented -- largely as a result of the desire to use LibreSSL as a generic replacement for OpenSSL. See Bernard Spil's wiki pages here: https://wiki.freebsd.org/OpenSSL/ There is a plan afoot to make all ported software only use SSL libraries from the ports, and reserve the base OpenSSL library as private to base system software. This will make SSL support in ports substantially easier, but it not here yet. Cheers, Matthew [*] which is currently base-OpenSSL, ports-OpenSSL, LibreSSL and maybe... a bunch of other contenders like GnuTLS, PolarSSL, WolfSSL. You've a reasonable assurance of success with the first three, but the rest are less commonly used, or have significant differences in their APIs, and more importantly, haven't had the work put in to make them generically portable[+]. [+] Also there's a question over whether these SSL libraries will be up to standard with the latest security ideas, such as obsoleting SSLv2, SSLv3 and TLSv1.0 in favour of TLSv1.1 or above. --3iGff33dd0OQu2gQRV0x72Gupe5E7iUk3-- --6BJ5OeDkLwdaXBx6vrCI6ooLkukiUGgDP Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQJ8BAEBCgBmBQJXd8vWXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQ2NTNBNjhCOTEzQTRFNkNGM0UxRTEzMjZC QjIzQUY1MThFMUE0MDEzAAoJELsjr1GOGkATgQoP/20w8EMPoKZFQCGg0RJ3qkMJ 0WpeXHVdvr0Hv2YrWCpd3vGyd86EKm4e9KkLaH/SLYUGPjCI7koki4enwHZtZVWb dK25N6g/ObsCC6RWAOmN2b32LjWyvzwr5U7aMC3SBpOsyCuApmwpo3Pj1srSblcl BP8dc5Xns99H9wOUQ+X97PJNhxLa0FHpSMX5L1wXDh2n1RizJcHbg7CgyDSijG2v ofTb2I930rreh9NuBxC3edFSprorxsyavBMweqYVy137EulymdA54Wt+EB6zDJ0/ 9ZH4U9T72nVwliz3tkpqoTPwfe+2F9m3i7250bjBAYjVe4f+Ilv4BWOlWbpkeoNz bW0rYw8c8JOqtQX0H0Djfnj7y/m7du+gdLrv6pHvWVC1Po6cCgaCqRFgM7bqLKfm /GFGjaFdrham4smqFoy2QW7WPEvzjnGQZBTkP00TlXl9f5EoY1CtknSknlD2ld6O kJw2gFJzmv+8WR1PJoSmndTdBp+XDj+w+6MxGO8+1IVx5h2Qt/seviaDULDjWoeU ezmYw1Db8jwxTWZJCyHnzqmhguKZObgBnSBYH/QFsCva5lkqMOqneXG2eWbQkMjl fd2/VqFkNFPlgjBB2T9ctBCEjfv51FzIB7hbfs02oxna+ookRK6CnWssaYvw8KtH D9pm5AtaLV1eJeRXOH2n =RXZT -----END PGP SIGNATURE----- --6BJ5OeDkLwdaXBx6vrCI6ooLkukiUGgDP--