javascript: uses unsafe-eval

[bg451]

Howdy,

Something recently came up with lightstep's javascript tracer implementation that I wanted to relay here. The protobuf library for browser javascript uses eval, creating a csp violation. There are currently two open tickets with no response: protocolbuffers/protobuf#5464 and protocolbuffers/protobuf#6770. There's an alternative protobuf implementation called protobuf.js but it also has the same issue: protobufjs/protobuf.js#593

Not really sure what there is to do with this, but it is a potentially massive gotcha depending on how strict the end user's security policies are.

[SergeyKanzhelev]

What's the action item here? Is it specific to JavaScript SIG and should be moved there?

[SergeyKanzhelev]

Based on description it looks like a JS library issue, not a schema problem. So I've transferred this issue

[draffensperger]

For Node, the content security policy I don't think would apply, so this is really only relevant to browser-specific code.

But I don't think we should be using protos directly in any code that gets shipped to the browser. What the OTel Collector exporter should do instead is to just essentially vendor the TS types for the JSON that will get sent to the collector (that corresponds via grpc-gateway to the protos). See this types file in OpenCensus Web.

cc/ @obecny

Does this seem right? Or am I missing something here?

[obecny]

From what I see now the opentelemetry-js is not using any package in browser that depends on google-protobuf. The only package that uses it is opentelemetry-plugin-grpc so far. But this package is the node.js package only. I'm not sure about electron apps - maybe this is something that should be checked separately although I think it should not cause any issues.

[pauldraper]

There's really no reason for OpenTelemetry to use any protos unless protos are already being used.

[rauno56]

For the reasons mentioned above the usage of eval is a concern for us as well, but we're not going to fix this locally.
Since no alternatives are suggested by the OP, that's more of an issue for protobuf.js repo than here.

[pauldraper]

The alternative is to use protobuf.js to generate the sources at compile-time (either through Node.js API or @harmony-dev/protobufjs-cli).

It's not an issue for protobuf.js; it already has support for non-eval.