-
-
Notifications
You must be signed in to change notification settings - Fork 1.8k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add org.microg.tools.CondLog() for conditional logging (for #251) #804
base: master
Are you sure you want to change the base?
Conversation
Very good idea, but I propose 2 DEBUG levels:
It could be set at compile time if there isn't any other way. |
microG has different log levels already, so we could either do more fine granulatio/re-classification or check whether we're on a debug build, instead of a relase build with something like:
|
There still can be the case when someone on a debug build need to post the log publicly (to help debugging). So I think we need a more fine granulation/reclassification of log messages (at least the ones containing sensitive informations or session ids that may allow session hijacking). |
See the last commit if it more fits your expectation, I've simply added DEBUG_SAFE (as CondLog.DEBUG_SAFE) as a new, custom log level, which equals to 42 (because it's the meaning of life). I've not hijacked the logger itself, because catching DEBUG_SAFE and then piping through Log.d() (or not) is enough from my point of view. Since official log levels are in the range between 2 - 7 that shouldn't cause any issue in the foreseeable future. Additionally isLoggable() will always return false for DEBUG_SAFE if we're on a release build. |
logs should never log sensitive information. this applies to every system. i shouldnt be exposed to risks if i choose DEBUG logs; this is a bug. i shouldnt need to know that a DEBUG_SAFE level exists not to be in danger! DEBUG should be safe, and if needed, a DEBUG_WITH_SENSITIVE_INFO or something similar could be added. (DEBUG_UNSAFE is not a good name; it doesnt protect users from phishing attacks from others posing as giving help.) more correctly, an independent LOG_SENSITIVE_INFO setting could be added which triggers logging of unsafe stuff at the proper level which probably shouldnt be DEBUG. a WARNING entry should be logged whenever this LOG_SENSITIVE_INFO mode is enabled. even if a DEBUG_WITH_SENSITIVE_INFO level is implemented, it should log a warning when selected. security is a serious thing. additionally, if DEBUG currently produces sensitive output, then id STRONGLY suggest removing that level completely. maybe replace it with VERBOSE or SAFE_DEBUG or something similar. the rationale would be avoiding this scenario where someone honest asks for a DEBUG log and is sent a tainted DEBUG from an old version of microg. |
You don't need to know about anything about DEBUG_SAFE (which maybe should be DEBUG_SENSITIVE instead?), this pull request would only allow logging of sensitive information in debug builds, ordinary users grab their apk from F-Droid or Github, so they are always on release builds.
Otherwise I agree mostly with you. Yes, microG currently logs stuff, you don't want it to. But at the end of the day, one shouldn't give away logcats unchecked. But, yes, not everyone has the knowledge.
This pull request should lay the basis to clean stuff up in user builds, but still leave the door open in debug builds.
Am 3. Juni 2019 15:53:26 MESZ schrieb Lanchon <[email protected]>:
…logs should never log sensitive information. this applies to every
system. i shouldnt be exposed to risks if i choose DEBUG logs; this is
a bug. i shouldnt need to know that a DEBUG_SAFE level exists not to be
in danger!
DEBUG should be safe, and if needed, a DEBUG_WITH_SENSITIVE_INFO or
something similar could be added. (DEBUG_UNSAFE is not a good name; it
doesnt protect users from phishing attacks from others posing as giving
help.)
more correctly, an independent LOG_SENSITIVE_INFO setting could be
added which triggers logging of unsafe stuff at the proper level which
probably shouldnt be DEBUG. a WARNING entry should be logged whenever
this LOG_SENSITIVE_INFO mode is enabled. even if a
DEBUG_WITH_SENSITIVE_INFO level is implemented, it should log a warning
when selected. security is a serious thing.
additionally, if DEBUG currently produces sensitive output, then id
STRONGLY suggest removing that level completely. maybe replace it with
VERBOSE or SAFE_DEBUG or something similar.
the rationale would be avoiding this scenario where someone honest asks
for a DEBUG log and is sent a tainted DEBUG from an old version of
microg.
--
You are receiving this because you authored the thread.
Reply to this email directly or view it on GitHub:
#804 (comment)
--
Diese Nachricht wurde von meinem Android-Gerät mit K-9 Mail gesendet.
|
If there's going to be 2 logging functions for each logging level, I agree with @Lanchon that the one that includes sensitive data should contain additional verbosity. In other words, we should use I would also suggest phrasing this with a preference of "sensitive data" over "sensitive info" to avoid confusion with the A global flag, off by default, should be as verbose and obvious as possible. Probably a good idea to put the words "DANGEROUS" and/or "I_KNOW_WHAT_IM_DOING" in there for good measure.
Even if we change future versions of microG to not use |
I've renamed DEBUG_SAFE to DEBUG_SENSITIVE to be more clear what's going on. Before going further we should wait for what @mar-v-in has to say regarding the logging. |
@voidstarstar: We must always tell users to upgrade to the latest microG before posting logcat otherwise we will have a lot of issues for already fixed bugs. @Nanolx: It seems nice but how can be switched on/off DEBUG_SENSITIVE in debug builds? |
@ale5000-git in the current state you can't, because it's always enabled in debug builds and always disabled in release builds. It would be possible to either a) add an optional compile time variable (override-able from |
My opinion is that for sensitive info it is safer a compile time variable, also it would be nice to avoid calling Log.isLoggable for DEBUG_SENSITIVE on DEBUG builds. |
Like this:
|
Yes, that's probably the best if we go with a). |
@mar-v-in any interest in this? If not, I'm going to close it. |
I personally prefer a system that by default removes sensitive information from log or replaces it with stars but keeps the log entries. And allows users to enable logging the sensitive information when needed. However, I'm not sure how to easily realize such system without significant additional burden during development. |
ae17355
to
8078073
Compare
Add new CondLog() [Conditional Logging] function to
play-services-core
. It only prints the Log if the desired Log.Level isLoggable(). Took some inspiration from this gist.Also includes a test commit within
AuthManagerServiceImpl
.@mar-v-in let me know if you think this is suitable for #251
cc-ing @ale5000-git @Lanchon