Our benchmarks saw a serious performance decrease with the upgrade from
Netty 4.1.88 to 4.1.94. The problem was tracked down to a single PR in
4.1.94, so we avoid 4.1.94 for now.
Fixes#10401
This updates the version of boringssl and removes the dependency on APR.
netty-tcnative 2.0.56.Final uses APR 1.7.0, so is in scope for
CVE-2021-35940, CVE-2022-28331, and CVE-2022-24963. netty-tcnative is
not actually vulnerable. The binary does not include apr_socket_sendv(),
apr_encode_*(), apr_pencode_*(), apr_decode_*(), apr_pdecode_*(). The
binary does include apr_time_exp_*() but it is unused code.
Unfortunately --gc-sections wasn't used during compilation.
apr_time_now() is used, but that just calls gettimeofday() and is not
vulnerable.
There's no panic here, but this updates netty-tcnative just a few weeks
before we would have ordinarily done so. Bumping the version makes life
easier for everyone.
There's still plenty more that could be done, but I want to keep this on
the simpler/less-invasive side and it'd just delay these changes for no
real benefit.
all: Update netty to 4.1.77.Final and netty_tcnative to 2.0.53.Final
Also switches to a non-release version of rules_jvm_external to allow Bazel build to work with artifact classifiers.
The tiny cache size was removed from the bytebuf allocator and so was
deprecated. TLSv1.3 was enabled by the upgrade, which fails mTLS
connections at different times. Conscrypt is incompatible with the
default TrustManager when TLSv1.3 is enabled so we explicitly disable
TLSv1.3 when Conscrypt is used for the moment.
The dns scheme is only the default scheme with grpc-java. Other
libraries could add more NameResolvers and thus change the default. For
compatibility reasons, the schema should therefore be specified
explicitly.
For security, we should change http into https links.
Co-Authored-By: Nguyen Van Trung [trungnvfet@outlook.com](mailto:trungnvfet@outlook.com)
Signed-off-by: Nguyen Quang Huy [huynq0911@gmail.com](mailto:huynq0911@gmail.com)
In testing, I discovered that Alpine does in fact work. Update the
documentation with the error you might see if you are simply missing a
package (for Googling) as well as fixes.
... with proper CA certificate to fix SSLV3_ALERT_HANDSHAKE_FAILURE in two host with different IPs setup, switch to required client auth to fail on incorrect configuration
Master currently is for grpc >= 0.11 so it doesn't make sense that the SECURITY.md instructs to use the 2.0.6 (which triggers an error) - see https://github.com/grpc/grpc-java/issues/3989
netty-handler has SslHandler which is really the piece that needs to
agree with netty-tcnative. But as I mention, all of netty should be a
consistent version, otherwise it may randomly break due to internal API
changes.
Eric Anderson