Skip to content

feat: enable use of keyrings #216

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

Merged
merged 25 commits into from
Mar 3, 2020
Merged

feat: enable use of keyrings #216

merged 25 commits into from
Mar 3, 2020

Conversation

mattsb42-aws
Copy link
Member

Issue #, if available: #211

Description of changes:

This adds support for using keyrings to DefaultCryptographicMaterialsManager as well as the appropriate passthroughs via CachingCryptographicMaterialsManager and the encrypt/decrypt entry points.

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.

Check any applicable:

  • Were any files moved? Moving files changes their URL, which breaks all hyperlinks to the files.

@mattsb42-aws mattsb42-aws requested a review from a team February 25, 2020 06:01
@mattsb42-aws mattsb42-aws changed the title Enable use of keyrings feat: enable use of keyrings Feb 25, 2020
@mattsb42-aws mattsb42-aws requested a review from seebees February 25, 2020 18:10
@mattsb42-aws
Copy link
Member Author

reminder for the record: Appveyor failing on 3.4 is a known issue and not caused by this PR

@seebees
Copy link
Contributor

seebees commented Mar 2, 2020

My questions have been resolved. @ajw-aws :)

provided_count = len([is_set for is_set in options_provided if is_set])

if provided_count != 1:
raise TypeError("Exactly one of 'backing_materials_manager', 'keyring', or 'key_provider' must be provided")
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is TypeError the best exception we can throw here? Is there a better custom exception class, or should we create one?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

TypeError is consistent with what built-ins and attrs throw if you provide incorrect parameters or types.

>>> def foo(b):
...     print("foo")
... 
>>> foo(3)
foo
>>> foo(b=3)
foo
>>> foo(f=3)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: foo() got an unexpected keyword argument 'f'
>>> foo(3, 4)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: foo() takes 1 positional argument but 2 were given


materials_are_valid = (
final_materials.algorithm is request.algorithm,
final_materials.encryption_context == request.encryption_context,
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is there a reason we have to use == here instead of is ?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Because we send a copy into the keyring rather than the original to avoid any potential side effects from misbehaving keyrings modifying it.

test = CachingCryptoMaterialsManager(
cache=MagicMock(__class__=CryptoMaterialsCache), max_age=10.0, master_key_provider=mock_mkp
cache=LocalCryptoMaterialsCache(capacity=10), max_age=10.0, master_key_provider=mkp
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Where does the magic number 10 come from? Should this instead be a declared constant elsewhere?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It's not magic, it's just a required parameter. It wasn't there before because I was using mocks before and now I'm actually using the actual class. IMO making it a constant would give it undue gravity; it really doesn't matter what number it is.

Copy link

@ajw-aws ajw-aws left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

Copy link
Contributor

@seebees seebees left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks good. Still learning Python :)

@mattsb42-aws mattsb42-aws merged commit 9ec35ef into aws:keyring Mar 3, 2020
@mattsb42-aws mattsb42-aws deleted the use-keyrings branch March 3, 2020 20:30
@mattsb42-aws mattsb42-aws mentioned this pull request Mar 4, 2020
10 tasks
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants