[GH-ISSUE #874] [FEATURE REQUEST] Paranoid logging mode #316

New issue

Open

opened 2026-02-27 08:16:36 +03:00 by kerem · 0 comments

kerem commented

2026-02-27 08:16:36 +03:00

Owner

Originally created by @nitnelave on GitHub (Mar 18, 2024).
Original GitHub issue: https://github.com/lldap/lldap/issues/874

Motivation
Most people don't want to share actual domain names/user names/emails when reporting an issue. Yet they appear in the logs. In general though, they are useful for an admin: they want the actual information. We need something to sanitize the logs before sharing them.

Describe the solution you'd like
I can think of 2 ways to do it:

the intrusive way, with an LLDAP config option that affects everything that gets logged, in depth. That would likely require rewriting debug representations for almost every struct we manipulate, not great.
the post-processing way: a bunch of regex, guided by the configuration, to remove common known patterns of information leak, potentially replacing them with stable obfuscated identifiers (so that we can still correlate them). Maybe as an LLDAP subcommand rather than a separate tool so that it would read the config? Although the values we read are few and stable, it's probably better to just make it a separate tool. This can potentially miss values to sanitize, though.

Originally created by @nitnelave on GitHub (Mar 18, 2024). Original GitHub issue: https://github.com/lldap/lldap/issues/874 **Motivation** Most people don't want to share actual domain names/user names/emails when reporting an issue. Yet they appear in the logs. In general though, they are useful for an admin: they want the actual information. We need something to sanitize the logs before sharing them. **Describe the solution you'd like** I can think of 2 ways to do it: - the intrusive way, with an LLDAP config option that affects everything that gets logged, in depth. That would likely require rewriting debug representations for almost every struct we manipulate, not great. - the post-processing way: a bunch of regex, guided by the configuration, to remove common known patterns of information leak, potentially replacing them with stable obfuscated identifiers (so that we can still correlate them). Maybe as an LLDAP subcommand rather than a separate tool so that it would read the config? Although the values we read are few and stable, it's probably better to just make it a separate tool. This can potentially miss values to sanitize, though.