Support using the system version of brotli #66462
Conversation
ghost
added
community-contribution
|
Tagging subscribers to this area: @dotnet/area-system-io-compression Issue DetailsThis is mainly motivated by the March 2022 release of .NET 5. .NET 5 was This is similar to the existing support for disabling distro-agnostic
|
omajid
force-pushed
the
system-brotli
branch
2 times, most recently
from
3ce0f94 to
5623c2d
Compare
omajid
changed the title
Does it fail at runtime as well; or is it just a problem with the verification script? |
The unit tests all passed, so it should be working at runtime. I think it's just a verification script issue. |
|
The easiest fix would be disable the verification script when using system brotli, and depend on tests to find problems if there are any. |
|
Yes. I'd disable verification when using system brotli. The verification is to catch if entry points are inconsistent in embedded case. |
|
Okay, I will undo my changes to entrypoints.c and verify-entrypoints.sh (which were locally working/passing for both bundled and system brotli) and simply skip verification for system brotli. |
|
I agree with this plan. |
omajid
force-pushed
the
system-brotli
branch
2 times, most recently
from
142ee68 to
029c1f8
Compare
This is mainly motivated by the March 2022 release of .NET 5. .NET 5 was found to be vulnerable to CVE-2020-8927, which was caused by the older version of brotli built into .NET. .NET was vulernable even in environments where a system-wide version of brotli was present and had already received fixes for this CVE. We could have avoided a Remote Code Execution vulnerability in such environments by using the system's version of brotli. This is similar to the existing support for disabling distro-agnostic OpenSSL (except no OpenSSL is embedded) and using the system libunwind (a copy of libunwind is embedded this repo). One small twist is the presence of entrypoint verification. In a system-brotli build, the verification fails, because the built library, libSystem.IO.Compression.Native.so, doesn't include the symbols for Brotli. Those symbols are instead used from the system brotli libraries.
|
Opened dotnet/arcade#8670 on the infrastructure failure |
This is mainly motivated by the March 2022 release of .NET 5. .NET 5 was found to be vulnerable to CVE-2020-8927, which was caused by the older version of brotli built into .NET. .NET was vulernable even in environments where a system-wide version of brotli was present and had already received fixes for this CVE. We could have avoided a Remote Code Execution vulnerability in such environments by using the system's version of brotli. This is similar to the existing support for disabling distro-agnostic OpenSSL (except no OpenSSL is embedded) and using the system libunwind (a copy of libunwind is embedded this repo). One small twist is the presence of entrypoint verification. In a system-brotli build, the verification fails, because the built library, libSystem.IO.Compression.Native.so, doesn't include the symbols for Brotli. Those symbols are instead used from the system brotli libraries.
ghost
locked as resolved and limited conversation to collaborators
This is mainly motivated by the March 2022 release of .NET 5. .NET 5 was
found to be vulnerable to CVE-2020-8927, which was caused by the older
version of brotli built into .NET. .NET was vulernable even in
environments where a system-wide version of brotli was present and had
already received fixes for this CVE. We could have avoided a Remove Code
Execution vulnerability in such environments by using the system's
version of brotli.
This is similar to the existing support for disabling distro-agnostic
OpenSSL (except no OpenSSL is embedded) and libunwind (a copy of
libunwind is embedded this repo).