getsentry / sentry

Developer-first error tracking and performance monitoring
https://sentry.io
Other
38.63k stars 4.14k forks source link

Configure Github source code repository mapping without giving source-code access #60510

Open sandstrom opened 10 months ago

sandstrom commented 10 months ago

Problem Statement

Problem

We cannot setup Sentry stack-trace source-code linking without giving full access to our source-code. But technically this shouldn't be required.

The reason for not giving you full source-code access, is that if you get hacked (like Solarwinds or Heroku), we don't want the hacker to extract our source-code.

This works great with the Sentry CLI, which we are using in Github actions. But for source-code mapping, your system won't allow me to only fill in base-url to the repo and branch name, it requires the app to have access (even though that's not strictly required).

Bugsnag

Bugsnag offer this without giving them access to source code.

CleanShot 2023-11-23 at 13 59 26

With Bugsnag, we'd set this using their CLI tool, which is one option. Another one would be to set it in the Sentry web UI somewhere.

https://docs.bugsnag.com/build-integrations/bugsnag-cli/create-build/#repository-repository

UI that I wish would change

CleanShot 2023-11-23 at 13 51 42

Solution Brainstorm

No response

Product Area

Settings - Repositories

getsantry[bot] commented 10 months ago

Assigning to @getsentry/support for routing ⏲️

getsantry[bot] commented 10 months ago

Routing to @getsentry/product-owners-issues for triage ⏲️

malwilley commented 10 months ago

@sandstrom thanks for the feedback!

We are currently working to make stack trace links work without source context, which will solve part of this problem: https://github.com/getsentry/sentry/issues/60219

However, this will still only work if you have a source code integration installed. If I understand you correctly, you would like stack trace links to work without the GitHub integration? This is certainly possible, although would require some significant work. We rely on the integration to confirm that the code mappings are correct and files actually exist, which would not be possible without having access to the repo. Although we could certainly redesign things to work without that assumption.

I'll add this to the backlog and we will discuss this as a followup to the work linked above.

sandstrom commented 9 months ago

@malwilley I see your point!

If I understand you correctly, you would like stack trace links to work without the GitHub integration?

Yes, that's correct.

Security concern with source-code access

My main argument would be that security-wise, many tools similar to you (Readme.io, Bugsnag, Linear and many others) are moving away from requiring full read access to source code.

With Github Actions, a push-based integration [data is pushed to you] is easy to setup, quicker (real-time instead of polling) and much more secure (we can SHA-pin your CLI tools, so even if you are hacked they won't get auto-compromised).

The recent attacks on Solarwinds and Heroku has shown that by having all that source code access, you are painting a target on your back [for hackers].

Suggested middle ground

I think one middle way might be to use the integration to confirm that a mapping is setup correctly, but also allow mappings to be configured and stay "unconfirmed". So basically, your UI could say something like "Since no Github integration is setup, we could not confirm your mapping, but as long as it's correct the source code linking will work".

(in Bugsnags case, they solved the "drift problem" by having these mappings sent to their server using the CLI, on every release, so that if a repo was renamed they would get the new mapping on the next release)

sandstrom commented 9 months ago

@malwilley I just noticed that a previous discussion I had with you in September has resulted in this being logged already: https://github.com/getsentry/sentry/issues/56255

The person at Sentry that I talked about at that time thought it was a good improvement.

So maybe you want to close this as a duplicate of the other (or the other way around)?

Or copy some of the details / discussion from this issue into this other one.

malwilley commented 9 months ago

@sandstrom thanks for pointing that out! I've closed the other issue since this one has all the wonderful context you've added.

Thank you again for your detailed feedback! This is under serious consideration.