[issue46200] Discourage logging f-strings due to security considerations

Arie Bovenberg added the comment: Thanks @gregory.p.smith! I didn't know about discuss.python.org. I created a new topic there: https://discuss.python.org/t/safer-logging-methods-for-f-strings-and-new-style-formatting/13802 -- ___ Python tracker

[issue46200] Discourage logging f-strings due to security considerations

Gregory P. Smith added the comment: A new system of logging APIs has been on several of our (core dev and otherwise) minds ever since f-strings were introduced. For this specific issue, agreed that documentation is key. The old logging APIs cannot change. And practically preventing passing

[issue46200] Discourage logging f-strings due to security considerations

Tin Tvrtković added the comment: I mean, I agree with your point about being able to accidentally format twice when using the standard library logger. I'm not a core dev but I think getting new APIs in will be challenging. And if by some fluke of chance you did get the approval to introduce n

[issue46200] Discourage logging f-strings due to security considerations

Change by Erlend E. Aasland : -- nosy: -erlendaasland ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: https:

[issue46200] Discourage logging f-strings due to security considerations

Arie Bovenberg added the comment: @rhettinger @tinchester I definitely see now that f-strings should have a place in logging. But do you agree that f-strings don't mix 100% safely with the current logger API? What are your thoughts on a safer set of logger functions (see my comments above,

[issue46200] Discourage logging f-strings due to security considerations

Raymond Hettinger added the comment: In a favor of deferred substitution, the cookbook should have a recipe where substituted messages are logged to a file and the unsubstituted message stored in SQLite3 database with the parameters stored as JSON.This gives both human readable output an

[issue46200] Discourage logging f-strings due to security considerations

Raymond Hettinger added the comment: > Eric is absolutely right, due to function calls being > somewhat slow in Python the performance argument in > practice falls in favor of f-strings. Also f-strings can evaluate expressions in the template which is also a big win: f('Pending {len(req)}

[issue46200] Discourage logging f-strings due to security considerations

Tin Tvrtković added the comment: Eric is absolutely right, due to function calls being somewhat slow in Python the performance argument in practice falls in favor of f-strings. So if they're faster, more readable, and more convenient to write, no wonder people prefer them (including me). The

[issue46200] Discourage logging f-strings due to security considerations

Arie Bovenberg added the comment: Indeed the `__format__` style offers a lot more options (see https://pyformat.info/). Regarding performance you make an interesting point. One possible solution is to allow f-strings _only_ if there are no args/kwargs. In that one case formatting would expli

[issue46200] Discourage logging f-strings due to security considerations

Eric V. Smith added the comment: I think there's definitely room for improvement here, and at face value I like the debugf() functions. __format__ style formatting solves a big problem for me: being able to provide format strings for timestamps. One thing: I'd be careful about saying that de

[issue46200] Discourage logging f-strings due to security considerations

Change by Erlend E. Aasland : -- nosy: +erlendaasland ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: https:/

[issue46200] Discourage logging f-strings due to security considerations

Arie Bovenberg added the comment: I've done some more digging, and have read the related issue bpo-30995. There are IMHO two challenges that are worth tackling: 1. A great number[1] of developers do their own string formatting. This is sub-optimal for performance and - in rare cases - l

[issue46200] Discourage logging f-strings due to security considerations

Arie Bovenberg added the comment: Absolutely agree! In practice I find some people are not swayed by this argument -- and prefer the readability of f-strings. My expectation is that a clear recommendation in the official docs will convince more people. Especially if there are security conce

[issue46200] Discourage logging f-strings due to security considerations

Vinay Sajip added the comment: Another (minor) point against using f-strings or .format is that formatting prematurely might be doing unnecessary work - by default, logging formats messages lazily, waiting until a message actually needs to be output. This could perhaps be more prominently em

[issue46200] Discourage logging f-strings due to security considerations

Change by Eric V. Smith : -- nosy: +eric.smith ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.p

[issue46200] Discourage logging f-strings due to security considerations

Change by Serhiy Storchaka : -- nosy: +vinay.sajip ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: https://ma

[issue46200] Discourage logging f-strings due to security considerations

New submission from Arie Bovenberg : (I've already submitted this issue to secur...@python.org, who directed me to propose a documentation change here) Logging f-strings is quite popular, because the `%` style of logging is often considered ugly. However, logging preformatted strings comes wi