Implement EventScrubber

[sl0thentr0py]

Add a new EventScrubber class that scrubs certain potentially sensitive interfaces with a DEFAULT_DENYLIST. The default scrubber is automatically run if send_default_pii = False.

Usage

from sentry_sdk.scrubber import EventScrubber, DEFAULT_DENYLIST

# custom denylist
denylist = DEFAULT_DENYLIST + ["my_sensitive_var"]

sentry_sdk.init(
    # ...
    send_default_pii=False,
    event_scrubber=EventScrubber(denylist=denylist),
)

As outlined in https://github.com/getsentry/rfcs/blob/main/text/0062-controlling-pii-and-credentials-in-sd-ks.md
closes #1897
docs: getsentry/sentry-docs#6489

[antonpirker]

Why not just walk the whole event structure recursively and apply scrub_dict()?

As the implementation is now, when we (or somenone else) adds a top level key "super_secret_stuff" it will not be touched.

[antonpirker]

I get that having those seperate scrubbing functions makes it convenient for a user to derive a custom scrubber that works like the original one, but does not scrub for example the breadcrumbs.

[antonpirker]

But maybe add a scrub_others or scrub_rest

That does something like:

for key in event.keys():
    if key not in ["request", "extra", "user", ...]:
        self.scrub_dict(event[key])

(or something like scrub_dict that walks the dict recursively and not only looks at the top level keys)

[sl0thentr0py]

Why not just walk the whole event structure recursively and apply scrub_dict()?

Only python has the Event as an opaque dict/object without interfaces, no other SDK does this, so I just went with a structure that would work for all SDKs. The recursive walking can only work in python sadly.

I think this is fine for a first version and we can see how and if users use this at all and wait for feedback.
I just wanted to have something like this as a first-class abstraction and this is a good first step.

[antonpirker]

Ok.
How can we ensure, that if we add some top level key to the event in the future, that we do not forget to update the default EventScrubber? Because we (or whoever is than working on this) will forget about this.

[sl0thentr0py]

we can't ensure and that's fine