Repository navigation
Third-party Sentry releases leak into projects without specific releases #791
Description
Activity
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.
Reacted by Rene Hamburger- moved this from Waiting for: Product Owner to No status in GitHub Issues with 👀 3
on Aug 14, 2025 We so far only have two ideas and both are not ideal:
- We add an SDK option, something like
readGlobalValues: boolean, which defaults totruebut 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
moduleMetadataIntegrationand themoduleMetadataplugin:
When we inject the release code into the JS code atrenderChunk, we know the filename. Also, if we throw anew 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 therenderChunkapproach but we inject the import to the virtual release file.- We add an SDK option, something like
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.)We could make it so that if you set
release: undefinedoninit, then we don't read from the globals?This would be a breaking change though since users might be relying on the current behaviour.
- moved this from Waiting for: Product Owner to No status in GitHub Issues with 👀 3
on Aug 15, 2025 We could make it so that if you set
release: undefinedoninit, then we don't read from the globals?This would be a breaking change though since users might be relying on the current behaviour.
What about
release: null?Either way, this comes very close to the work-around. Would be really good to achieve some kind of scoping for those global variables.
Another thought: what if your bundle plugins stopped creating global variables and rather replaced a specific placeholder in the code with release version?
We could make it so that if you set release: undefined on init, then we don't read from the globals?
Not a fan of making a difference between not setting a value and setting it to
undefinedtbh.What about release: null?
I guess this would be a bit better 😅 Though I'm fairly sure that users with a lenient/non-existing type checking setup set
nullwith the same objective of not setting it at all.As already stated, the main issue with this is that you as a "conventional" app developer have to set this to avoid being spammed with releases from browser extensions. Ideally, there's a world where this can be fixed by at its root.
Another thought: what if your bundle plugins stopped creating global variables and rather replaced a specific placeholder in the code with release version?
We could think about this yes. It needs to be implemented is a backwards-compatible way though. Meaning, the SDK must take the release from 1.
Sentry.init, 2. the replaced placeholder if set, 3. from the global object if set, 4. otherwise not at all.We'll need to discuss this a bit more internally what to do here.
Reacted by Rene Hamburger and Tim Fish- moved this from Waiting for: Product Owner to No status in GitHub Issues with 👀 3
on Aug 25, 2025
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_RELEASEor__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.