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

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.

> 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.

> 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.

-- 
Sergey A. Osokin