[pininja]

Do you think having a set of opt-out functions/decorators for sensitive variables would be comforting?

I could see it going either way. I would probably not use this globally on programs using secrets, but would consider opting-in occasionally where chances are low and value high.

[cricalix]

Consider the scenario where you develop a daemon that does something, has no secrets that you worry about. You implement this concept of automatic logging of variables, and all is well in the world.

You leave. New person takes over ownership, doesn't notice the import. Urgent business need says "add this feature to the daemon" and now it's processing secrets. Now, you can argue that the person who took ownership should have read the code more carefully, but perhaps it's their 5th day on the job when that request comes in, or they misread the import as something else.

I suppose you could do a code standard of "variables that containe a secret must always have 'secret' as a prefix", and could then do pattern matching, but humans are going to human and make a mistake.

I'd probably lean towards opt-in, decorator/context only - maybe "@traceback_with_variables_can_log_secrets" as the name...

[arafsheikh]

> Do you think having a set of opt-out functions/decorators for sensitive variables would be comforting?

Opt-out is risky and I’d not want to use it in sensitive applications.

Instead, opt-in would be as good as deliberately logging variables but without the additional log/print statements and try/catch blocks.