Hacker News Reader

Comment by arafsheikh | Hacker News Reader

Neat idea but it doesn’t look like something I’d be comfortable using in production. A useful feature to have would be to selectively tag the variables I want to track (in the decorator perhaps?). This way one can prevent printing sensitive info or potentially large variables in the logs.

View on HN

Agree - which is why I use Sentry, which has sensible default and configurable PII filters [0] for staging/production.

For debugging, eh, why not - but I've not previously had the need to enable this, let's say, application-wide (where I see the most advantage compared to just adding dumps of locals() per stack).

[0] https://docs.sentry.io/platforms/python/configuration/option...

Blind logging of all variables (as the writeup implies) is definitely a nightmare. You can end up with things like passwords, credit card details etc in the logs. If you're running a log concentrator, now they're in the concentrator - and did you remember to set ACLs on who can read from the concentrator (assuming the servers have good ACLs already for reading logs directly from prod servers)?

In dev, sure (assuming local disk only). In prod, not in the form documented.

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.

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...

> 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.

I wrote https://github.com/skorokithakis/tbvaccine years ago for the same purpose, and the fix is simple: Just don't install it on production.

It requires no changes to your code, you can install it system-wide and all tracebacks will be prettified.

+1 this seems like a GDPR/CCPA nightmare when it comes to potentially spewing user data into logs.

Reply on news.ycombinator.com