pam: Use safer handler for debugging bubble tea messages without disclosing information

[3v1n0]

When debug mode is enabled, during ssh sessions we are disclosing some new-password information.

So avoid this to happen, but also take the occasion to make the messages logging safer and more helpful in debug and test builds so that we can show all the information when it's safe, while not expose anything relevant in release builds.

UDENG-6647

[codecov-commenter]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 85.41%. Comparing base (424966b) to head (1a00d17).

Additional details and impacted files

@@            Coverage Diff             @@
##             main     #876      +/-   ##
==========================================
- Coverage   85.45%   85.41%   -0.05%     
==========================================
  Files          80       80              
  Lines        5550     5588      +38     
  Branches      109      109              
==========================================
+ Hits         4743     4773      +30     
- Misses        752      756       +4     
- Partials       55       59       +4     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[denisonbarbosa]

Isn't this "too much effort" to format something that we are in control of? If this kind of changes are necessary, I think that maybe we should take another look at our debug messages and do a better job at avoiding leaking secrets in those messages rather than using this logic, no?

[3v1n0]

Maybe... But at this point the effort has been mostly done already 😅 and since this leak happened after that some time ago we saw others, I just preferred to have a central place to ensure we can protect info and format better others... Instead than checking continuously every single place were we debug

[adombeck]

I agree that this feels like too much effort. On the other hand, we are logging bubbletea messages in a lot of places, and should make sure that we don't log any user secrets in any of those. In the diff, it looks like many of those places are after after a switch-case-statement which checks the message type, so maybe we don't need the check in most of those, and the number of places where we need to actually consider whether the message could contain a secret or not becomes manageable? I would trust @3v1n0's best judgement here, since he is the one who has to deal with this code base the most.

As a side note, I hope that one day we can rewrite this code and get rid of bubbletea, which will hopefully reduce a lot of complexity and make it easier to figure out what's going on (including what we're actually printing with a debug statement).

[3v1n0]

In the diff, it looks like many of those places are after after a switch-case-statement which checks the message type, so maybe we don't need the check in most of those, and the number of places where we need to actually consider whether the message could contain a secret or not becomes manageable?

Sure, but I also wanted to improve the logging for other specific cases, and this code is basically a no-op when no debugging is enabled, so an extra-type check in such case isn't a big deal.

Thus, from my POV this is the safest way we have at the moment to both achieve:

• Good logging if required (tests and dev builds)
• Tested safe logging elsewhere