3 ms·

No, the critique (as I understand it) is that it's not using the system library but building it from scratch. From the description it's not binding his BoringS

No, the critique (as I understand it) is that it's not using the system library but building it from scratch. From the description it's not binding his BoringSSL .so or .dll that exists on the system and building it, it's compiling its own pinned version and using that. If it was using the system library and a vulnerability was found in it and the distro shipped a fixed package, then the swift coding using it would benefit from that fix without any recompilation needed (for back-patching distros at least, which is from my experience what people use in production systems). Ideally, even if you manually compiled BoringSSL for your system and the distro wasn't providing it, you could build again from a newer version or at worst patch the source of the library you originally built and rebuild it. Automatically building a specific version of a library, which may not be (and likely won't be) the latest version of that library with the latest security fixes, is a real problem. Now, I don't know if BoringSSL was pulled in from vapor, or a dependency vapor relies on, but it is problematic to have the language libraries do this, at least if there isn't an option to do otherwise (and maybe there was, and it just wasn't surfaced through the layers as vapor built its dependencies). This might very well also be a problem with vapor and not swift, as it could be other swift modules do the right thing.

estebank 3y ago
This is a good call-out, the issue around vendoring, but it seemed to me that the complaint was about using BoringSSL at all. It is a very valid complaint if dependencies are vendoring their dependencies, side-stepping your system. On Rust-land, I've noticed that some libraries like to have a fallback or compile time config flag to use the vendored version, but still provide a way of using the system's version. I appreciate when both options are available because I've encountered some C libs that were very difficult to set-up on first run and the vendored version usually works out of the box.
- kbenson 3y ago
  > but it seemed to me that the complaint was about using BoringSSL at all. From the article: "but it raises the bigger question of why are we compiling BoringSSL in the first place?" (emphasis mine). I think the "compiled" part of that is doing the heavy lifting. > On Rust-land, I've noticed that some libraries like to have a fallback or compile time config flag to use the vendored version, but still provide a way of using the system's version. This is probably a good middle ground, but it might be more harmful than helpful than if it instead just linked to direction for how to install it yourself (at the simplest level it's almost always ./configure; make; make install), because then at least it's obvious what happened and what libs are being used and you can find them (in /usr/local or wherever). > I appreciate when both options are available because I've encountered some C libs that were very difficult to set-up on first run and the vendored version usually works out of the box. Anything that the install process can automate should be easy enough to provide directions and maybe some simple helper scripts for. If it's too complicated for someone to do, how is it able to be done in an automated fashion by a dependent in a way that seems to work for most people? (and if it doesn't work for most people, why even offer it)

estebank 3y ago

This is a good call-out, the issue around vendoring, but it seemed to me that the complaint was about using BoringSSL at all. It is a very valid complaint if dependencies are vendoring their dependencies, side-stepping your system. On Rust-land, I've noticed that some libraries like to have a fallback or compile time config flag to use the vendored version, but still provide a way of using the system's version. I appreciate when both options are available because I've encountered some C libs that were very difficult to set-up on first run and the vendored version usually works out of the box.

kbenson 3y ago
> but it seemed to me that the complaint was about using BoringSSL at all. From the article: "but it raises the bigger question of why are we compiling BoringSSL in the first place?" (emphasis mine). I think the "compiled" part of that is doing the heavy lifting. > On Rust-land, I've noticed that some libraries like to have a fallback or compile time config flag to use the vendored version, but still provide a way of using the system's version. This is probably a good middle ground, but it might be more harmful than helpful than if it instead just linked to direction for how to install it yourself (at the simplest level it's almost always ./configure; make; make install), because then at least it's obvious what happened and what libs are being used and you can find them (in /usr/local or wherever). > I appreciate when both options are available because I've encountered some C libs that were very difficult to set-up on first run and the vendored version usually works out of the box. Anything that the install process can automate should be easy enough to provide directions and maybe some simple helper scripts for. If it's too complicated for someone to do, how is it able to be done in an automated fashion by a dependent in a way that seems to work for most people? (and if it doesn't work for most people, why even offer it)