OTEL: update code to remove use of some deprecated options

[thaJeztah]

Description

• tracking ticket for vendor: OTEL v0.46.1 / v1.21.0 #47245 (comment)
• related to OTEL: update code to remove use of some deprecated options buildkit#4681

Looks like this needs some local changes (either temporary //nolint for the release branches if we want to backport, or changes in code);

api/server/router/grpc/grpc.go:24:69: SA1019: otelgrpc.StreamServerInterceptor is deprecated: Use [NewServerHandler] instead. (staticcheck)
	stream := grpc.StreamInterceptor(grpc_middleware.ChainStreamServer(otelgrpc.StreamServerInterceptor(), grpcerrors.StreamServerInterceptor))
	                                                                   ^
api/server/router/grpc/grpc.go:49:15: SA1019: otelgrpc.UnaryServerInterceptor is deprecated: Use [NewServerHandler] instead. (staticcheck)
	withTrace := otelgrpc.UnaryServerInterceptor()
	             ^
libcontainerd/supervisor/remote_daemon.go:304:32: SA1019: otelgrpc.UnaryClientInterceptor is deprecated: Use [NewClientHandler] instead. (staticcheck)
					grpc.WithUnaryInterceptor(otelgrpc.UnaryClientInterceptor()),
					                          ^
libcontainerd/supervisor/remote_daemon.go:305:33: SA1019: otelgrpc.StreamClientInterceptor is deprecated: Use [NewClientHandler] instead. (staticcheck)
					grpc.WithStreamInterceptor(otelgrpc.StreamClientInterceptor()),
					                           ^
daemon/daemon.go:965:29: SA1019: otelgrpc.UnaryClientInterceptor is deprecated: Use [NewClientHandler] instead. (staticcheck)
		grpc.WithUnaryInterceptor(otelgrpc.UnaryClientInterceptor()),
		                          ^
daemon/daemon.go:966:30: SA1019: otelgrpc.StreamClientInterceptor is deprecated: Use [NewClientHandler] instead. (staticcheck)
		grpc.WithStreamInterceptor(otelgrpc.StreamClientInterceptor()),
		                           ^

StreamServerInterceptor, UnaryServerInterceptor, and StreamClientInterceptor were deprecated in open-telemetry/opentelemetry-go-contrib@23bd4ed

• otelgrpc: Deprecate interceptors in favor of stats handlers open-telemetry/opentelemetry-go-contrib#4534

[raghu017]

@thaJeztah Thank you for working to fix the Otel vulnerabilities

#47246 (comment)
Regarding above comment from @neersighted

I understand and respect the position of the Moby project. However, I wanted to provide some context for our urgency. The requirement to have zero vulnerabilities is a mandate from the US Federal government to its contractors. This particular vulnerability, flagged by scanner tool, has been present since October. It's been a significant amount of time and the issue is still unresolved.

Given the timeline and the government mandate, we are now compelled to remove the dockerd dependency from our application. The vulnerability must be addressed in our application by March 4th.

[neersighted]

Greetings @raghu017,

I am sorry to say that the position of the project is very clear, and that further agitation to perform a backport that the maintainers have concluded is unnecessary or dangerous is indicative of a lack of understanding and respect for this project.

It sounds to me as if you have successfully built a business on top of this project (and implicitly, the community/contributors, processes, and source code within). I'm glad that you are able to do so -- certainly as a maintainer, I would like to encourage and see more diverse and successful usage of this project, both commercially and by hobbyists.

However, it seems I must remind you of the warranty and guarantees that this project (and its contributors) make to you, the consumer of the source code:

moby/LICENSE

Lines 144 to 152 in 81428bf

	7. Disclaimer of Warranty. Unless required by applicable law or
	agreed to in writing, Licensor provides the Work (and each
	Contributor provides its Contributions) on an "AS IS" BASIS,
	WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or
	implied, including, without limitation, any warranties or conditions
	of TITLE, NON-INFRINGEMENT, MERCHANTABILITY, or FITNESS FOR A
	PARTICULAR PURPOSE. You are solely responsible for determining the
	appropriateness of using or redistributing the Work and assume any
	risks associated with Your exercise of permissions under this License.

moby/LICENSE

Lines 166 to 175 in 81428bf

	9. Accepting Warranty or Additional Liability. While redistributing
	the Work or Derivative Works thereof, You may choose to offer,
	and charge a fee for, acceptance of support, warranty, indemnity,
	or other liability obligations and/or rights consistent with this
	License. However, in accepting such obligations, You may act only
	on Your own behalf and on Your sole responsibility, not on behalf
	of any other Contributor, and only if You agree to indemnify,
	defend, and hold each Contributor harmless for any liability
	incurred by, or claims asserted against, such Contributor by reason
	of your accepting any such warranty or additional liability.

You must understand that any promises, guarantees, or SLAs you have made regarding your products are yours alone. This project is open source, open to contributions from all sources, and driven by the needs of its contributors. Of course, this is at times imperfect and messy, but we try our best to steward the project and look after smaller user's needs as well.

As the project is open source, you are of course welcome to contribute, or to make modifications to the code, shared with others (or not) as long as you follow the terms of the license (see above). If you are unhappy with a decision made by the maintainers, such as not performing a backport you desire, you are welcome to (and indeed encouraged to) perform your own backport and deliver the resulting product to your customers.

I must once again highlight to you that it falls upon you, not this project, to ensure that the artifacts you deliver to your customers are suitable for their purposes, and compliant with the terms of any contract you may have signed with them.

You have received an official response from this project, both as to the substance of the CVE-2023-47108 finding (note: this is a finding, not a vulnerability, as dockerd is not vulnerable according to the established security model), and as to the suitability of #47245 for backport to a release branch.

Please demonstrate your understanding and respect for the project, its contributors, and its license by ceasing to agitate upstream for an action that will not be taken, and instead direct your energies to resolving your customer's concerns (and your apparent contractual obligations) according to the terms of the license, and the remedies you have as a user (and indeed, vendor) of open source software.

Please also understand that future agitation along this line (having been asked to cease two times, and having exhausted any productive discussion) may result in the removal of your ability to interact with, contribute to, and fully participate in the project.