Add a (b)ack option to 'Is this a valid secret?' Closes Issue #63 #72

cleborys · 2018-08-30T19:17:33Z

Add going backwards option to 'Is this a valid secret?', closing Issue #63

This would be my first contribution to open source ever - thank you for the "good first issue" flag!

I have not yet figured out how to run the tests properly, else I would try to be test-driven.

The two directions I could see this go in are currently (preferences welcome):

(the "obvious" one) Make _secret_generator in core/audit.py a list instead of a generator and handle indices in audit_baseline
Cast _secret_generator to a "bidirectional iterator" object (still goes through list). That adds some overhead, but keeps the for ... in _secret_generator of audit_baseline and might make audit.py more readable.

cleborys · 2018-08-30T20:05:20Z

.gitignore

@@ -1,6 +1,7 @@
 *.egg-info
 *.py[co]
 *.sw[op]
+.secrets.baseline


.secrets.baseline felt like it should only be in a local copy. I might be mistaken.

Ahh, that is confusing, sorry about that, it is purposefully meant to be included in the Git repo though.

Thanks, I re-added it :)

KevinHock · 2018-09-03T01:09:17Z

This would be my first contribution to open source ever

That's really awesome :D 🎈 🍰 🎉

I'll get back to you on Tuesday or Wednesday with possible implementation preferences.

next call of `__next__` would look like. Does not work properly yet (can only step back if last choice was `s` and counter at top does not decrease properly.

… to check how to do this properly)

domanchi · 2018-09-04T18:02:07Z

Bidirectional iterator looks good! Looking forward to tests!

KevinHock

Looks great so far 👍

detect_secrets/core/bidirectional_iterator.py

KevinHock · 2018-09-04T22:57:22Z

detect_secrets/core/bidirectional_iterator.py

+            raise StopIteration
+        return result
+
+    def next(self):


~~Nit: Looping should call the __next__ method directly, so no need for a next method~~ 👍

I added next to be python2 compatible (it was renamed form next to __next__ from python2 to 3).
However, this does not feel very clean - perhaps you know of a better way? :)

Aha! Very good point, I only tested on Python 3. My bad. I am impressed by how thorough you are 👍

cleborys · 2018-09-07T18:58:26Z

Is there an assumption that secrets in the results of the baseline are in a fixed order? (I mean the lists baseline['results'][filename])
If not I would re-write merge_results in baseline.py to remove this assumption so that it works with updates to the baseline that are out-of-order.
That would simplify some choices in audit_baseline of audit.py a lot :)

domanchi · 2018-09-07T19:06:51Z

@cleborys: currently, no there isn't. It's a Python dictionary for O(1) access by filename (and because the JSON dump is human readable), but that means key iteration cannot be depended on for order.

It's a good point though -- and would simplify testing and other logic. Maybe you would like to work on it as a next PR? =D If we sort the keys before iterating through it, that should fix stuff.

cleborys · 2018-09-07T19:19:52Z

@domanchi Sorry, I am a bit confused 😅
I meant the list that is stored under the filename key and contains the secrets in that file. The merge_results function assumes that updates to that list are in order so that it is easier to update, but that now means I have some problems when stepping back on choices in the audit:

Currently the audit iterates over all secrets and automatically skips these that already had the is_secret flag set. But that means that when I skip back one secret after I previously chose y or n, it will be automatically skipped again, hence the back option currently only works correctly when the last option chosen was skip.
Instead I would like to change the loop to only iterate over secrets without the is_secret flag set and then append all previously known secrets that had there flag set already. But that would shuffle the list of secrets (the lists that are stored by filename) and I'm not sure if it is ok to shuffle this (after removing the "order" assumption of merge_results.

I am not completely confident that that would work as stated, because simply removing the "has is_secret-flag already set, then skip"-condition seems to produce lots of identical secrets to be shown, so there seems to be an extra effect that I don#t understand yet 😉

KevinHock

LGTM 🚢 , thanks a bunch for making this 😁

cleborys · 2018-09-07T19:32:31Z

@KevinHock Thanks :) But it is not yet functional! Only the framework with the new iterator works yet, so don't merge 😉

(I don't really know the etiquette yet - I made a pull request already so that you can see whats happening, but I wouldn't remove the [WIP] tag in the title until it is functional and I think I'm done. So I hope your approval doesn't mean that you intend to merge)

domanchi · 2018-09-07T19:41:57Z

@cleborys, ah, I understand you better now.

Yes, the secrets in the list are ordered. One benefit of this is comparing side by side diffs of baselines - and it's very easy to see the changes between iterations. You can quite easily see whether a secret has been removed, added, or appropriately labelled. By reordering the contents, it becomes that much harder to see differences, if applicable.

For example, if you start the audit process with pre-existing audited secrets, but not perform any additional labelling, you would expect no changes to the baseline.

If the goal is to allow the back option to iterate over previously labelled secrets, perhaps you can just append that to the if statement?

e.g. something like

if 'is_secret' not in secret or decision == 'b':
    blah

cleborys · 2018-09-07T19:47:52Z

@domanchi Cool, I will not mess around with the order then 😅
Yes, I will try something like this. it is not completely straightforward, because you don't want to have the user step back into secrets that were previously autoskipped and that he is not aware of.
I think I will, before the decision loop runs, split the list into secrets shown to the user and secrets not shown, then iterate over the secrets to be shown, and then interlace the results in the correct order, afterwards :)

…d merged afterwards. Stepping back now functional.

cleborys · 2018-09-07T20:26:54Z

It seems I had forgotten how Python works ("everything is a pointer") and in the end the necessary changes were much easier.

The user decision loop now only loops over secrets which don't have the is_secret flag set and decisions modify them in-place. So the order is kept and there is no need to backtrack changes when they are overridden. The results dict by filename is constructed after the user is done and then merged.

I expect that everything works as it should now, but I'll add some tests to make sure 😄

…. This enables going back and overriding a previous choice with 'skip'

cleborys · 2018-09-07T21:28:20Z

Tests written and passing, manual sanity checks also successful! 🎉 🎈
Thanks, guys! Ready for final review.

KevinHock

LGTM, gonna merge :D

Provide (b)ack option to user.

244220b

cleborys commented Aug 30, 2018

View reviewed changes

KevinHock self-requested a review September 3, 2018 00:41

cleborys added 3 commits September 3, 2018 15:40

First draft of what an iterator that can be told to step back once on

49235f7

next call of `__next__` would look like. Does not work properly yet (can only step back if last choice was `s` and counter at top does not decrease properly.

removing from gitignore

5405b34

iterator python2 compatibility hack: define that will call (I'll need…

fe723e2

… to check how to do this properly)

KevinHock reviewed Sep 4, 2018

View reviewed changes

Unit tests for BidirectionalIterator

2d4c160

domanchi approved these changes Sep 7, 2018

View reviewed changes

KevinHock approved these changes Sep 7, 2018

View reviewed changes

Audit loops only over secrets with decision, result is constructed an…

1134973

…d merged afterwards. Stepping back now functional.

cleborys added 2 commits September 7, 2018 22:39

_handle_user_decision now deletes flag if skip decision 's' is passed…

6e922b8

…. This enables going back and overriding a previous choice with 'skip'

Integration tests for going back and overwriting decisions

2a6995c

cleborys changed the title ~~[WIP] Add a (b)ack option to 'Is this a valid secret?' Closes Issue #63~~ Add a (b)ack option to 'Is this a valid secret?' Closes Issue #63 Sep 7, 2018

KevinHock approved these changes Sep 11, 2018

View reviewed changes

KevinHock merged commit f7d05ac into Yelp:master Sep 11, 2018

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Add a (b)ack option to 'Is this a valid secret?' Closes Issue #63 #72

Add a (b)ack option to 'Is this a valid secret?' Closes Issue #63 #72

cleborys commented Aug 30, 2018 •

edited

Loading

cleborys Aug 30, 2018

KevinHock Sep 3, 2018

cleborys Sep 7, 2018

KevinHock commented Sep 3, 2018

domanchi commented Sep 4, 2018

KevinHock left a comment

KevinHock Sep 4, 2018 •

edited

Loading

cleborys Sep 7, 2018

KevinHock Sep 7, 2018

cleborys commented Sep 7, 2018 •

edited

Loading

domanchi commented Sep 7, 2018

cleborys commented Sep 7, 2018

KevinHock left a comment

cleborys commented Sep 7, 2018

domanchi commented Sep 7, 2018

cleborys commented Sep 7, 2018 •

edited

Loading

cleborys commented Sep 7, 2018

cleborys commented Sep 7, 2018 •

edited

Loading

KevinHock left a comment

Add a (b)ack option to 'Is this a valid secret?' Closes Issue #63 #72

Add a (b)ack option to 'Is this a valid secret?' Closes Issue #63 #72

Conversation

cleborys commented Aug 30, 2018 • edited Loading

cleborys Aug 30, 2018

Choose a reason for hiding this comment

KevinHock Sep 3, 2018

Choose a reason for hiding this comment

cleborys Sep 7, 2018

Choose a reason for hiding this comment

KevinHock commented Sep 3, 2018

domanchi commented Sep 4, 2018

KevinHock left a comment

Choose a reason for hiding this comment

KevinHock Sep 4, 2018 • edited Loading

Choose a reason for hiding this comment

cleborys Sep 7, 2018

Choose a reason for hiding this comment

KevinHock Sep 7, 2018

Choose a reason for hiding this comment

cleborys commented Sep 7, 2018 • edited Loading

domanchi commented Sep 7, 2018

cleborys commented Sep 7, 2018

KevinHock left a comment

Choose a reason for hiding this comment

cleborys commented Sep 7, 2018

domanchi commented Sep 7, 2018

cleborys commented Sep 7, 2018 • edited Loading

cleborys commented Sep 7, 2018

cleborys commented Sep 7, 2018 • edited Loading

KevinHock left a comment

Choose a reason for hiding this comment

cleborys commented Aug 30, 2018 •

edited

Loading

KevinHock Sep 4, 2018 •

edited

Loading

cleborys commented Sep 7, 2018 •

edited

Loading

cleborys commented Sep 7, 2018 •

edited

Loading

cleborys commented Sep 7, 2018 •

edited

Loading