3 ms·

It seems weird to disqualify boringssl due to live-at-head project philosophy. Obviously _your_ project doesn't have to change every time boringssl changes.

toast0 1y ago
The only way that really works is if HAProxy includes the version of BoringSSL they want to use in their source tree. Otherwise, it's too hard for users to find the right version. But you quickly get to the hard problems of when there are security fixes for BoringSSL. Upstream is only going to fix it on head per their philosophy. So either someone has to backport the fix to whatever version HAProxy uses on their supported versions, or HAProxy has to update to head with whatever gymnastics required on all their supported versions. In the meantime, it's probably more difficult for users to understand if their system has a vulnerable version of boringssl, because it's embedded into HAProxy, and not a separate package. Given that, it makes a lot of sense to not consider it, when AWS-LC is a fork of BoringSSL that's intended to be used by 3rd party projects.
jeroenhd 1y ago
Their project has LTS versions that need to support the stuff that was supported on the date the release was made. BoringSSL doesn't do versioned/LTS releases, so their code happily moves on, deprecating/altering/removing features as they see fit. You could do fake LTS releases of BoringSSL, manually backporting features and fixes, but that's a lot of work with little pay-off. Once a feature gets removed at HEAD and bugs/vulnerabilities/whatever get found in that feature, you're stuck figuring it out yourself, and altering all future code that the feature depended on to keep it compatible. Combining live-at-HEAD and LTS versions is a pain. There's nothing wrong with either approach, but combining the two is asking for trouble, especially for libraries where you can't just pin a commit and hope for the best like core security libraries.

toast0 1y ago

The only way that really works is if HAProxy includes the version of BoringSSL they want to use in their source tree. Otherwise, it's too hard for users to find the right version. But you quickly get to the hard problems of when there are security fixes for BoringSSL. Upstream is only going to fix it on head per their philosophy. So either someone has to backport the fix to whatever version HAProxy uses on their supported versions, or HAProxy has to update to head with whatever gymnastics required on all their supported versions. In the meantime, it's probably more difficult for users to understand if their system has a vulnerable version of boringssl, because it's embedded into HAProxy, and not a separate package. Given that, it makes a lot of sense to not consider it, when AWS-LC is a fork of BoringSSL that's intended to be used by 3rd party projects.

jeroenhd 1y ago

Their project has LTS versions that need to support the stuff that was supported on the date the release was made. BoringSSL doesn't do versioned/LTS releases, so their code happily moves on, deprecating/altering/removing features as they see fit. You could do fake LTS releases of BoringSSL, manually backporting features and fixes, but that's a lot of work with little pay-off. Once a feature gets removed at HEAD and bugs/vulnerabilities/whatever get found in that feature, you're stuck figuring it out yourself, and altering all future code that the feature depended on to keep it compatible. Combining live-at-HEAD and LTS versions is a pain. There's nothing wrong with either approach, but combining the two is asking for trouble, especially for libraries where you can't just pin a commit and hope for the best like core security libraries.