This PR does 2 distinct things, I can unbundle them if desired
1) Add functions in `ssl_transport_security_utils` and associated tests that will eventually be used for additional Crl validation (the logic of actually doing this will be in a future PR), so other than the tests these fns are currently unused.
2) Remove the use of `X509_NAME_oneline` - it is not a guaranteed stable way to get the issuer name for lookups. Instead, use the DER encoding via `i2d_X509_NAME` - the results in a non-human readable string that is stable for lookup, and necessitated some change to the CrlProvider test code that previously used a human readable string for this value.
Neither should result in behavior changes.
Closes#35641
COPYBARA_INTEGRATE_REVIEW=https://github.com/grpc/grpc/pull/35641 from gtcooke94:CrlRefactor 2b6f63717c
PiperOrigin-RevId: 607701254
This reverts commit a18279db2e.
<!--
If you know who should review your pull request, please assign it to that
person, otherwise the pull request would get assigned randomly.
If your pull request is for a specific language, please add the appropriate
lang label.
-->
Closes#35850
PiperOrigin-RevId: 607476066
<!--
If you know who should review your pull request, please assign it to that
person, otherwise the pull request would get assigned randomly.
If your pull request is for a specific language, please add the appropriate
lang label.
-->
Closes#35891
COPYBARA_INTEGRATE_REVIEW=https://github.com/grpc/grpc/pull/35891 from yousukseung:work_serializer ca36cde216
PiperOrigin-RevId: 607380601
Discuss thread about this change: [link](https://mail.google.com/mail/u/0/#sent/QgrcJHsBpWNGRlrMktwbppGGfFTVCFLcQgL?compose=new)
<!--
If you know who should review your pull request, please assign it to that
person, otherwise the pull request would get assigned randomly.
If your pull request is for a specific language, please add the appropriate
lang label.
-->
Closes#35849
PiperOrigin-RevId: 607144827
- Dropped Ruby 2.7 test (Ruby 2.7 hit EOL 1 year ago)
- Upgraded the base image of Ruby docker images from Debian:10 to Debian:11 (Debian:10 hit EOL)
Closes#35911
PiperOrigin-RevId: 607088383
Change was created by the release automation script. See go/grpc-release.
Closes#35899
COPYBARA_INTEGRATE_REVIEW=https://github.com/grpc/grpc/pull/35899 from eugeneo:bump_dev_version_202402131133 73950425c9
PiperOrigin-RevId: 606777850
CC @youyuanwu
This fixes a lock acquisition ordering problem in WindowsEventEngine's Connect behavior, between a ConnectionState's internal mutex, and a HandshakeManager's mutex. The connection state mutex should not be held when calling the on_connected callback.
This should unblock #34801Closes#35892
COPYBARA_INTEGRATE_REVIEW=https://github.com/grpc/grpc/pull/35892 from drfloob:connect-callback-lock-cycle 4d56120e2f
PiperOrigin-RevId: 606752276
As title. Pulling these additions out from a larger change.
Related: cl/563857636
Closes#35860
COPYBARA_INTEGRATE_REVIEW=https://github.com/grpc/grpc/pull/35860 from apolcyn:test_lib_changes 40b6455638
PiperOrigin-RevId: 606708025
It could happen that we start two writes on the same endpoint simultaneously, leading to awesome results.
Closes#35900
COPYBARA_INTEGRATE_REVIEW=https://github.com/grpc/grpc/pull/35900 from ctiller:write-order 1f7559d7b9
PiperOrigin-RevId: 606707912
Continues #35412 addressing feedback in https://github.com/grpc/grpc/pull/35412#issuecomment-1875980755
I'm unable to test the workspace with the newly added py_test, so I'm hoping a CI run here will tell me if the test works.
```console
~/grpc/test/distrib/bazel/python$ bazel --nohome_rc --nosystem_rc test //...
Loading:
Loading:
Loading: 0 packages loaded
Analyzing: 37 targets (0 packages loaded, 0 targets configured)
ERROR: /usr/local/foobar/home/sloretz/.cache/bazel/_bazel_sloretz/7f83b4f00f370e7c52a5cc586445673c/external/com_google_protobuf/upb_generator/BUILD:266:21: @com_google_protobuf//upb_generator:protoc-gen-upb_toolchain: no such attribute 'output_files' in 'proto_lang_toolchain' rule
ERROR: /usr/local/foobar/home/sloretz/.cache/bazel/_bazel_sloretz/7f83b4f00f370e7c52a5cc586445673c/external/com_google_protobuf/upb_generator/BUILD:305:21: @com_google_protobuf//upb_generator:protoc-gen-upb_minitable_toolchain: no such attribute 'output_files' in 'proto_lang_toolchain' rule
ERROR: /usr/local/foobar/home/sloretz/.cache/bazel/_bazel_sloretz/7f83b4f00f370e7c52a5cc586445673c/external/com_google_protobuf/upb_generator/BUILD:338:21: @com_google_protobuf//upb_generator:protoc-gen-upbdefs_toolchain: no such attribute 'output_files' in 'proto_lang_toolchain' rule
ERROR: /usr/local/foobar/home/sloretz/.cache/bazel/_bazel_sloretz/7f83b4f00f370e7c52a5cc586445673c/external/com_google_protobuf/upb_generator/BUILD:305:21: Target '@com_google_protobuf//upb_generator:protoc-gen-upb_minitable_stage1' contains an error and its package is in error and referenced by '@com_google_protobuf//upb_generator:protoc-gen-upb_minitable_toolchain'
ERROR: /usr/local/foobar/home/sloretz/.cache/bazel/_bazel_sloretz/7f83b4f00f370e7c52a5cc586445673c/external/com_github_grpc_grpc/src/proto/grpc/gcp/BUILD:19:14: every rule of type proto_library implicitly depends upon the target '@com_google_protobuf//upb_generator:protoc-gen-upb_minitable_toolchain', but this target could not be found because of: Target '@com_google_protobuf//upb_generator:protoc-gen-upb_minitable_toolchain' contains an error and its package is in error
ERROR: Analysis failed
ERROR: Analysis of target '//namespaced/upper/example:no_import_no_strip_py_pb2_grpc' failed; build aborted:
INFO: Elapsed time: 0.171s
INFO: 0 processes.
FAILED: Build did NOT complete successfully (0 packages loaded, 0 targets configured)
ERROR: Couldn't start the build. Unable to run tests
```
Closes#35629
PiperOrigin-RevId: 606695865
Change was created by the release automation script. See go/grpc-release.
Closes#35889
COPYBARA_INTEGRATE_REVIEW=https://github.com/grpc/grpc/pull/35889 from eugeneo:bump_core_version_202402121600 dfab90395b
PiperOrigin-RevId: 606635870
Add a step in distribution test which checks if any of the artifacts exceeds 80 MB since Pypi has a per-file size limit.
<!--
If you know who should review your pull request, please assign it to that
person, otherwise the pull request would get assigned randomly.
If your pull request is for a specific language, please add the appropriate
lang label.
-->
Closes#35831
COPYBARA_INTEGRATE_REVIEW=https://github.com/grpc/grpc/pull/35831 from XuanWang-Amos:dist_test_add_size_check de50f20e14
PiperOrigin-RevId: 605664419
As discussed, this change adds scoping to `CsmObservability` such that when that object goes out of scope, new channels and servers don't record metrics. In the documentation, I've talked about how existing channels/servers are going to continue to record metrics but i've left room for us to change that behavior in the future.
The current way of doing this is through a global bool since there can only be one plugin right now, but we'll change this to use the global stats plugin registry in the future.
Closes#35835
COPYBARA_INTEGRATE_REVIEW=https://github.com/grpc/grpc/pull/35835 from yashykt:DisableCsmObsOnScope 33a7c2f7bc
PiperOrigin-RevId: 605468117
The Oauth2 credentials currently rely on pollsets and polling entities, partially because grpc_core::HttpRequest relies on them as well. This is a temporary solution to get both iomgr and EventEngine clients to pass the oauth2 interop tests.
Tested with the client experiment on and off.
Closes#35866
COPYBARA_INTEGRATE_REVIEW=https://github.com/grpc/grpc/pull/35866 from drfloob:oauth2_utils_work_with_ee_hack 91eea0c196
PiperOrigin-RevId: 605433817
<!--
If you know who should review your pull request, please assign it to that
person, otherwise the pull request would get assigned randomly.
If your pull request is for a specific language, please add the appropriate
lang label.
-->
Closes#35832
COPYBARA_INTEGRATE_REVIEW=https://github.com/grpc/grpc/pull/35832 from gnossen:strip_armv7 0cb7a3122c
PiperOrigin-RevId: 605401618
Core team [moved resolver code](https://github.com/grpc/grpc/pull/35804) to `src/core/resolver`, our build is failing because we have a dependency on it and the resolver folder is not copied to `observability/grpc_root`:
* `call_tracer.h` -> `core_configuration.h` -> `lb_policy_registry.h` -> `lb_policy.h` -> `endpoint_addresses.h`
To fix this issue and to prevent such issues from happening again, instead of subfolders, we'll copy all files from `src/core` to `observability/grpc_root/src/core`.
<!--
If you know who should review your pull request, please assign it to that
person, otherwise the pull request would get assigned randomly.
If your pull request is for a specific language, please add the appropriate
lang label.
-->
Closes#35845
COPYBARA_INTEGRATE_REVIEW=https://github.com/grpc/grpc/pull/35845 from XuanWang-Amos:fix_o11y_core_header_deps 3c9eb8c499
PiperOrigin-RevId: 605063207
Fixes#33935
The gRPC spec is not clear on how to handle headers where the "content-type" is not "application/grpc" or similar. We should be safe and not reject such headers.
Closes#35824
COPYBARA_INTEGRATE_REVIEW=https://github.com/grpc/grpc/pull/35824 from yashykt:Fix33935 3d89af87ec
PiperOrigin-RevId: 604742049
<!--
If you know who should review your pull request, please assign it to that
person, otherwise the pull request would get assigned randomly.
If your pull request is for a specific language, please add the appropriate
lang label.
-->
Closes#35792
PiperOrigin-RevId: 604695910
Closes#35076. See discussion there for context.
Previously, if `getpeername` failed on a recently-accepted Unix domain socket, the server would shut down. It's unclear if there's any valid reason `getpeername` would fail here, we could be looking at system issues / data corruption, but it may be implementation-dependent. I did not find a man page that specified this behavior: getpeername on a server errors with `EBADF` when a client closes its end of a UDS connection; the server's fd should still be valid. I was not able to reproduce the failure on recent Linux/Mac systems where clients close their connection after a listener accepted (basic, non-gRPC test: listener accepts a connection and sleeps, client closes their end, then listener wakes up and calls getpeername).
If there are no valid reasons `getpeername` would fail in these spots, gRPC behavior is essentially undefined - we cannot defensively code around system failures in every place they may occur. If this _is_ a valid situation on some platforms, then this fix keeps the server alive as one would hope. There are arguments to be made for shutting down servers if the system is unstable, but I can't find an objectively correct behavior here. For those reasons, I think it may be best to keep the server running, which is what this PR does.
Closes#35823
COPYBARA_INTEGRATE_REVIEW=https://github.com/grpc/grpc/pull/35823 from drfloob:abort-listen-on-failed-getpeername 29e723c5bb
PiperOrigin-RevId: 604694057
Esun Kim
Gregory Cooke
Xuan Wang
Craig Tiller
Yousuk Seung
youyuanwu
Alexander Polcyn
Eugene Ostroukhov
Mark D. Roth
AJ Heller
Shane Loretz
gRPC Team Bot
erm-g
Yash Tibrewal
Richard Belleville