-
Notifications
You must be signed in to change notification settings - Fork 25
[POC|PM-28135] Add crypto tracing logs #555
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
base: main
Are you sure you want to change the base?
Conversation
|
Great job! No new security vulnerabilities introduced in this pull request |
Codecov Report❌ Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## main #555 +/- ##
==========================================
- Coverage 79.54% 79.41% -0.14%
==========================================
Files 303 303
Lines 32464 32288 -176
==========================================
- Hits 25824 25641 -183
- Misses 6640 6647 +7 ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
|
Note: This has some overlap with #550, as this also enables tracing. The linked PR enables tracing and removes log. |
dani-garcia
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks pretty reasonable to me, just got some small comments.
|
Do we have any concerns about runtime performance? I think tracing negatively impacts performance but they have ways to indicate some should be compiled out, https://docs.rs/tracing/latest/tracing/level_filters/index.html#compile-time-filters. (I suspect tracing performance to be a drop in the bucket for the crypto operations but I think this is a worthwhile discussion to have) |
Co-authored-by: Daniel García <[email protected]>
|
Claude encountered an error —— View job I'll analyze this and get back to you. |
|
@Hinton My biggest concern would be if tracing somehow is blocking with respect to the subscribers, and we would log a lot (possibly having to go to JS every time via the hooking to console it uses), though a quick check suggests that it just appends to a buffer that then gets flushed, and actual logs should not be that frequent with the current implementation. Is there specific things that you'd like to see measured here? Vault unlock times for large vaults? Actual logs should only be emitted for errors / rare info events, but obviously the context is still stored into a buffer somewhere. |
|
@quexten Comparing calling decrypt 100'000 times with tracing to 100'000 without in a test maybe? I think it's a drop in the bucket. But I feel like it's probably not necessary to be honest. I do think it's good to decide if we want any of the |
|
@Hinton Okay, I've not further benchmarked it since I agree that it's most likely negligible. I've set the max log level to In case we do want logging in an operation that gets called millions of times, we should consider using debug/trace to have it compiled out in release. |
🔍 SDK Breaking Change Detection ResultsSDK Version:
Breaking change detection completed. View SDK workflow |

🎟️ Tracking
https://bitwarden.atlassian.net/browse/PM-28135
📔 Objective
Enables
tracing, but does not yet remove the old logging (follow-up). It adds tracing to the most important crypto paths. Follow-up tickets may add more tracing.Example log output:
⏰ Reminders before review
team
🦮 Reviewer guidelines
:+1:) or similar for great changes:memo:) or ℹ️ (:information_source:) for notes or general info:question:) for questions:thinking:) or 💭 (:thought_balloon:) for more open inquiry that's not quite a confirmedissue and could potentially benefit from discussion
:art:) for suggestions / improvements:x:) or:warning:) for more significant problems or concerns needing attention:seedling:) or ♻️ (:recycle:) for future improvements or indications of technical debt:pick:) for minor or nitpick changes