BF: do not crash, just skip whenever trying to delete non existing field in the underlying keyring#5892
Merged
yarikoptic merged 1 commit intodatalad:maintfrom Aug 18, 2021
Conversation
…ssw in keyring Fixing bug leading to a crash: We have pairs or more in composite credentials. If user saved some but not all of them, then upon renew whenever we try to delete them all we would crash here since keyring cannot delete the ones it does not yet know. So the easiest (although adhoc due to need to match msg) is to handle such an exception. To get it tested, I had to use a "real" keyring's backend (so they are called), and for that I had to RF our Keyring helper class to be capable of being provided a keyring backend instance (or in other words -- a "keyring"). An odd logic abit I left behind is that even though we are now explicitly asking for what keyring will be used, so we could store/use that instance if no explicit backend is provided, but for consistency with current behavior (since to go against maint), decided to keep it as is and keep using module level bound interfaces of keyring module in case if no backend instance was provided. So now ._keyring could be either keyring module (no backend instance provided, or actual keyring backend if it was provided (used only in the tests). Added test also tests basic assumption that keyring is storing the name somewhere, and deletes entire section whenever we delete entire credential. Relies on "ad-hoc" way to specify the filename. Somewhat inquired in jaraco/keyrings.alt#45 on a better way. Closes datalad#5889
yarikoptic
added
credentials
Codecov Report
@@ Coverage Diff @@
## maint #5892 +/- ##
===========================================
- Coverage 90.34% 29.60% -60.74%
===========================================
Files 300 297 -3
Lines 42396 42387 -9
===========================================
- Hits 38302 12549 -25753
- Misses 4094 29838 +25744
Continue to review full report at Codecov.
|
yarikoptic
added
the
merge-if-ok
mih
approved these changes
Aug 15, 2021
Member
Author
|
thank you @mih. Yeah -- was thinking the same about |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Fixing bug leading to a crash: We have pairs or more in composite
credentials. If user saved some but not all of them, then upon renew whenever
we try to delete them all we would crash here since keyring cannot delete the
ones it does not yet know. So the easiest (although adhoc due to need to match
msg) is to handle such an exception.
To get it tested, I had to use a "real" keyring's backend (so they are called),
and for that I had to RF our Keyring helper class to be capable of being
provided a keyring backend instance (or in other words -- a "keyring"). An odd
logic abit I left behind is that even though we are now explicitly asking for
what keyring will be used, so we could store/use that instance if no explicit
backend is provided, but for consistency with current behavior (since to go
against maint), decided to keep it as is and keep using module level bound
interfaces of keyring module in case if no backend instance was provided.
So now ._keyring could be either keyring module (no backend instance provided,
or actual keyring backend if it was provided (used only in the tests).
Added test also tests basic assumption that keyring is storing the name
somewhere, and deletes entire section whenever we delete entire credential.
Relies on "ad-hoc" way to specify the filename. Somewhat inquired in
jaraco/keyrings.alt#45 on a better way.
Closes #5889