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.
OpenPGP_signature.asc
Description: OpenPGP digital signature
