Third-party Sentry releases leak into projects without specific releases

[rene-leanix]

Environment

We are using @sentry/angular@9.22.0 in our web-app.

Expected Result

Only the releases we define in our use of the SDK or which we create in Sentry via the API or the GitHub action should be assigned to our projects.

Actual Result

We have observed that a large number of third-party release were created for our Sentry fall-back project, for which we deliberately never set or create a release. As it turned out, these releases are injected via the global SENTRY_RELEASE or __SENTRY_RELEASE__ variables that your bundler plugins create for third-party scripts, such as browser extensions, and are then applied to our project during the run-time of the SDK.

Here is one example: The release 1.25.0-b91f378 assigned to our fallback-project comes from the lace browser extension. The version is generated here and added as a Sentry version by your Webpack plugin. If a user now visits our web app with this plugin being loaded, our SDK code will pick up the release from the global variable set by the plugin on the shared window object.

Workaround

Our current workaround is to explicitly clear the release field in our code before it is sent to your servers.

Long-term solution

I would expect the code that the plugin generates to be associated with the Sentry project it is injected for to be able to only assign this version at run-time if the project matches.

[linear]

BUNDLER-78 Third-party Sentry releases leak into projects without specific releases

[andreiborza]

Hi @rene-leanix, thanks for looking into this and filing it. We discussed this a bit internally and haven't landed on a good solution yet. For now, please continue using your work-around of removing the releases field.

[Lms24]

We so far only have two ideas and both are not ideal:

• We add an SDK option, something like readGlobalValues: boolean, which defaults to true but you could opt out of it to avoid the situation you described. My main pain point with that is that it puts the burden on the majority of users but doesn't fix it properly.
• We somehow find a key that both the bundler plugins at build time and the SDK at runtime can agree on and we map the release values to these keys instead of just putting them onto the global directly. The problem is that there is no obvious key to do this automatically. For example, the DSN only contains the projectId while at build time we only know project and org slugs. Not even using the SDK version as a key is trivial because due to the timing of when we inject the release code snippet.

So we're definitely open to other suggestions. Also gonna tag @timfish - any ideas?

UPDATE: Actually, we could do something similar to moduleMetadataIntegration and the moduleMetadata plugin:
When we inject the release code into the JS code at renderChunk, we know the filename. Also, if we throw a new Error() at SDK init time, we should get the file name. So we could use that filename as the key 🤔 This is just a bit problematic for webpack where we don't use the renderChunk approach but we inject the import to the virtual release file.

[rene-leanix]

For example, the DSN only contains the projectId while at build time we only know project and org slugs.

Here's another hacky solution: could your bundle plugins scan the code for Sentry DSN strings and add the project-IDS collected from this as metadata to the global variable containing the release?? (You would probably use a new variable for this, e.g. __SCOPED_SENTRY_RELEASE__, and used this one rather than __SENTRY_RELEASE__ if it's available.)

[timfish]

We could make it so that if you set release: undefined on init, then we don't read from the globals?

This would be a breaking change though since users might be relying on the current behaviour.