Re: Best practice for port that are meant to be statically linked, or how should we handle boringssl

On 2023-11-27 17:48, Sergey A. Osokin wrote:
> Hi,
> 
> On Sun, Nov 26, 2023 at 11:07:21PM -0800, Xin Li wrote:
>>
>> I recently noticed that security/boringssl is treated in a similar way of
>> OpenSSL and LibreSSL.  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.
> 
> There's no releases for BoringSSL.

By bad, different *revisions*.

>> 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).
> 
> Generally speaking, I don't think this is the good idea to link a binary
> to both OpenSSL/LibreSSL _and_ BoringSSL.

No, I'm not proposing that application should be linking against both, 
but with the current way of shipping boringssl, it's installing header 
files and shared libraries (libcrypto.so and libssl.so) that could be 
picked up by any other ports who may not want boringssl at all.

For example, there is no www/envoy package today, while it should be 
perfectly fine to have a statically linked 'envoy' binary to co-exist 
with other OpenSSL based ports and work together.

>> Should we follow this?  And is using something like ${PREFIX}/eboringssl a
>> good model?  (I think ultimately we need something like it).
> 
> A project, that wants to be depended on BoringSSL needs to be aware that
> last one is not intended for general use, as OpenSSL or LibreSSL is.
> Follow that the project needs to keep its source code consistent with
> changes, that BoringSSL project does, on daily basis.