traceback_with_variables is not safe for production use due to password leaking, yet the documentation states "keep for production use"

[zzzeek]

Hi -

I am receiving CVE reports that my library (SQLAlchemy) is dumping passwords into log files. it of course is not, they are using this package in production to dump all private variables into their logs. I don't see any mechanism by which traceback_with_variables could recognize password strings that are necessarily present as cleartext within third party libraries.

I would propose that traceback_with_variables' documentation be amended to note that this tool is not safe for production use in any scenario where there are passwords or other secrets present at runtime. That way I can point people to this documentation when my package (or any of thousands of other packages that receive a password and/or secret within a private variable) is claimed to have CVEs in it.

Demo:

from traceback_with_variables import activate_by_import

def connect_to_something_witha_secret(host, username, password):
    raise Exception(f"could not connect to host: {host}")


def go():
    connect_to_something_witha_secret(
        "fakehost", "scott", "super_secret_password"
    )


go()

output:

Traceback with variables (most recent call last):
  File "/mnt/photon_home/classic/dev/sqlalchemy/test4.py", line 13, in <module>
    go()
      ...skipped... 12 vars
  File "/mnt/photon_home/classic/dev/sqlalchemy/test4.py", line 8, in go
    connect_to_something_witha_secret(
  File "/mnt/photon_home/classic/dev/sqlalchemy/test4.py", line 4, in connect_to_something_witha_secret
    raise Exception(f"could not connect to host: {host}")
      host = 'fakehost'
      username = 'scott'
      password = 'super_secret_password'
builtins.Exception: could not connect to host: fakehost

[andy-landy]

Hi Mike, sorry for the inconvenience and thanks for sparing time to address this issue here!

Yeah, let's fix that.
My problem is that such generic and simple tools like this one cannot really demand much from users as they focus the broadest crowd :/

At the moment I've got:

• the doc saying: Should I use it after debugging is over, i.e. in production? Yes, of course! That way it might save you even more time (watch out for sensitive data like passwords and tokens in you logs). Note: you can deploy more serious frameworks, e.g. Sentry :)
• custom filters like filter=(lambda name: 'pass' in name)

The trouble is that the basic usage can't rely on advanced users' actions :/

So my plan A is to

• add bold red notice on passwords
• add some simple password filters to the default mode, like 'pass' in name

[zzzeek]

Hi Andy -

thanks for your reply! A note in the docs about passwords / production is all I am asking for, since when I scanned I didn't see anything mentioning it. That would be great, thanks very much!

• mike