From nobody Tue Nov 28 06:37:27 2023 X-Original-To: freebsd-ports@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4SfXnN17z8z535cb for ; Tue, 28 Nov 2023 06:37:28 +0000 (UTC) (envelope-from danfe@freebsd.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2610:1c1:1:6074::16:84]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "freefall.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4SfXnN0gNRz3dRP; Tue, 28 Nov 2023 06:37:28 +0000 (UTC) (envelope-from danfe@freebsd.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1701153448; 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=SPhapa84tQ3JWtTnPQy6Vwih5CZENLFTeYu1M65fag4=; b=fbS6M7aR39jDqFpP4n5OA0LuVmXbFXuhQlkG6R+6wCWusJzVcDbdrm/olMRqQ1BzuVw/Gl kSkPXBYJqRvMxK6JtI1CmHSuu7tRBmONCbrxkEuPVqnKwE8Toqn/TqxfW70eVgSfXmHJcb iqxsDi7uqnCZ6EfzUFZStkoLFq2+kfVi/AkXiu25c5+wrscTMa9AmyDtvTsHSVMCFE+Hss nVRlfPXfViezyADh7w2d+/Ie5LcW7XcHpwTgY3YVV4DFnXND35TmfacjWwGhVZJmZc7vFC lqAWX137Vd5D5WMibQXAocURQMaLKiwoinbJhVaUE8cj13L2UTF01QNR1io2ZQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1701153448; 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=SPhapa84tQ3JWtTnPQy6Vwih5CZENLFTeYu1M65fag4=; b=KrJ1mM7RmCbAhfbzFJ84eaxpcyvdpjsxsOwsS4W6YJcCjh/U7duXUkbmDIc+Iq9Koy58hN m7B0XC5fQ+8RAPlNDH/spr/tIdRDmtN0HQdPRpJS4Q0JOgA1ZzjKHClJ8GgKXWG4dipwQ9 KIFf6D6uofPmkg7cHHBMi6UAigyv5+CcKH5qGMdUsZ1t40pwgdCbxko9PjiJdYk4bPkfLy 4vv0/KlhSvvwjxfoEk1bpi/qltTmYVoSTDLURIhmPsygZv4693GhJAZainS/Ok7SDBQmuC m6OxM2gjeB79dxWaTBhPSOa+9jJP2CPiTtlNf3weBiUwlLcvCk3BxpH9UossLQ== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1701153448; a=rsa-sha256; cv=none; b=kIHPyhxgZj7fG6krfqdEaUdhge5NR6FuJIlbNp11VpCa8m9rMVqTJUiRcxgKbkUbgpMXVR WbUqSs60IjCfyqmEnr7HUvU1R7xhmWektr9p7h5evm+mjgASFDX2cwavOkBgrcpcUDdFuF 5ZI4OqF+A8vJUsQ2zhTuxzoSxD2ReQyfH+lRua9uAr+8wOtFsYzx8BN9qRxGHApftHwXxQ 83rTCAdP8rO/kV7U5IoHJPFSgInqMkPLK4XbixNsSIo6AlXAy4IxhyBOy8SQmFn7xyqN4Q 11W9TF30C6JkmFkpjtPP8z9XWDIfk+8rsp2YexRhnIKE+1NV1gLXxMQNNIQAww== Received: by freefall.freebsd.org (Postfix, from userid 1033) id E541010DB9; Tue, 28 Nov 2023 06:37:27 +0000 (UTC) Date: Tue, 28 Nov 2023 06:37:27 +0000 From: Alexey Dokuchaev To: d@delphij.net Cc: freebsd-ports@freebsd.org, osa@freebsd.org Subject: Re: Best practice for port that are meant to be statically linked, or how should we handle boringssl Message-ID: References: <7a92ad42-b45d-46d4-b2f2-54b4bfcf2e93@delphij.net> List-Id: Porting software to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-ports List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-ports@freebsd.org X-BeenThere: freebsd-ports@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <7a92ad42-b45d-46d4-b2f2-54b4bfcf2e93@delphij.net> On Sun, Nov 26, 2023 at 11:07:21PM -0800, Xin Li wrote: > Hi, > > I recently noticed that security/boringssl is treated in a similar way > of OpenSSL and LibreSSL. Technically, `security/boringssl' cannot be treated similarly, i.e. it cannot be made one of possible SSL providers (via USES=ssl) because of circular dependency (it requires CMake which itself requires SSL). > Although boringssl is derived from OpenSSL, it's usually meant to be > statically linked into the resulting binary, because there is no > guarantee of ABI stability across different releases and the caller > is expected to evolve fast enough to follow the latest version of it. I was playing with that idea to get `www/envoy' packaged, later found out there is OpenSSL-based fork and decided to go that way, but could not complete the quest. :( > OpenBSD seems to be going though the statically linked route and they > install boringssl into ${PREFIX}/eboringssl instead of the regular > ${PREFIX}. This way, it's no longer conflicting with other OpenSSL/ > LibreSSL installation (technically, it still is, but only if the binary > links against both OpenSSL/LibreSSL _and_ boringssl). > > Should we follow this? And is using something like ${PREFIX}/eboringssl > a good model? (I think ultimately we need something like it). I wouldn't mind, albeit ultimately I'd rather see Google push their changes in the stock OpenSSL and bury their silly fork. ./danfe