Provide an ability to mask/exclude certain keys when printing show_locals=True

[datajoely]

Hello! We've just started our journey of adopting rich on kedro, the first part of this journey introduced the rich logging handler + pretty tracebacks.

We've just had a user, quite rightly, highlight that show_locals has printed out some credentials in plain text. The immediate fix for this is to set show_locals=False, which we will fix quickly.

My question is as follows, would you accept a PR where we allow the user to exclude certain keys when printing out the stack trace? I think it would go somewhere in this dictionary comprehension:

rich/rich/traceback.py

Line 376 in aea574a

locals={

Thanks!

[willmcgugan]

Agree in principal. Another (possibly complimentary) option might be to have a specially crafted local attribute with a set of keys to exclude from locals.

Something like:

def get_password(self):
    _rich_exclude_locals = {"password"}

This would be more granular than a global black list.

If we were to add a blacklist, perhaps it should accept a list of regexes?

[antonymilne]

Matching regexes sounds like a good suggestion to me.

If possible it would be useful to somehow mask/remove subkeys also. For example if I have a local variable config = {"password": 1234}, just matching by key password wouldn't work because it's nested inside a variable config. I don't know if this would be easy to do on rich though: presumably you would need to search through all of pretty.traverse(value) to detect arbitrarily nested exclude patterns. And what if config isn't a dictionary but some other structure that contains password as an attribute?

If this isn't possible then on the kedro side we will need to exclude credentials and any other variables that include it (like config). But there's nothing stopping a user from putting their credentials in another variable that isn't blacklisted on the framework side. Also it would be a bit of a pity to lose all of the config variable from the locals when it's just the credentials bit we're trying to remove.

[willmcgugan]

That would be possible with atomic data structures. For other objects you can't really know what attributes will be displayed in the repr. It would also be unwise to iterate over the attributes on an object as Rich may end up invoking arbitrary code via properties etc.

It would be possible for Rich to omit arbitrary __repr__ calls to prevent user code from leaking credentials. You may miss out on some useful debugging information, but that might be a reasonable compromise.

[danielgafni]

+1, this seems like a big security issue for production

[willmcgugan]

I'd still accept a PR if anyone proposes an elegant solution, but frankly showing locals is a debug aid, and should always be disabled in production.

[github-actions]

I hope we solved your problem.

If you like using Rich, you might also enjoy Textual