Repository navigation
Conversation
GitServer.handle and GitRelay.forward held the provider token as a plain string. Sentry's SDK sends every frame's local variables with an error report, and Sentry's SDK configuration turns off the scrubber that would replace a local named `token`. So in Sentry's git endpoint (getsentry/sentry#128444), every refusal after the token is fetched, such as an unreachable provider or a rejected token, would report it. get_token now returns an scm.Secret, which shows as [Filtered]. The relay reveals it only inline, for the ASCII check and HTTPBasicAuth. GitServer refuses a plain string with a TypeError, after dropping it from its frame: one that got past the type checker would otherwise fail every request in the relay and report the token. Breaking: get_token must wrap the token it returns, e.g. Secret(access_token.token).
This was referenced Oct 27, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
When Sentry's git endpoint (getsentry/sentry#128444) refuses a request after it has fetched a provider token, for example because the provider is unreachable or rejects the token, the error report carries the token. Sentry's SDK sends the local variables of every frame in the traceback, Sentry's SDK configuration turns off the scrubber that would otherwise replace a variable named
token, andGitServer.handleandGitRelay.forwardboth hold the token as a plain string. #162 fixed this for grant secrets and the grant, but left the token astr.Approach
GetTokenreturnsscm.Secret | None, andGitServer.handlepasses theSecreton toGitRelay.forward, so both frames show[Filtered]. The relay callsreveal()only inline, for the ASCII check andHTTPBasicAuth.GitServer.handlerefuses a token that isn't aSecretwith aTypeError, deleting the local first so that error's report doesn't carry it either. A plain string from untyped code would otherwise fail every request in the relay with anAttributeErrorwhose frames hold it.bin/git-serverwraps its tokens.get_tokennow has to wrap the token inSecret. Nothing calls it yet: Sentry's endpoint is still unmerged and will wrap it when it bumps to the release with this change.Not covered: an error the relay's adapter raises itself, such as Sentry's
BlacklistAdapterrefusing an internal address, passes through urllib3's frames, which hold theAuthorizationheader. The relay can't mask those, soGitRelay's docstring now says to report such an error without its frames' local variables; Sentry's endpoint handles that separately.