-
Notifications
You must be signed in to change notification settings - Fork 86
feat(test_vector_handlers): TestVectors test with MPL constructs #650
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
Conversation
) | ||
) | ||
|
||
# Weird hack #2: |
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.
Weird hack #2 is NOT present in Java.
Java test vectors use a modified keys.json file from other manifests: https://github.com/aws/aws-encryption-sdk-java/blob/master/src/test/resources/keys.json#L45
This is changed from "key-id": "rsa-4096-private"
to "key-id": "rsa-4096"
; similarly on the public key.
This allows the edk.keyProviderInfo == keyring.keyName
check to pass, and the keyring "works".
But (afaik) all of these vector suites provide their own keys.json
that still have key-ids
that specify private
/public
, so Java would not work with those vector suites.
This code should probably be in the TestVectors Dafny. It's only here because I debugged this in Python, and want some feedback before changing the Dafny.
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.
I'm not sure I'm following, I follow up.
This sounds like these hacks are fighting. The name of the key and the name of the key info are not the same thing.
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.
I'd describe it as "coordinating" rather than fighting :)
The primary evidence for this is that the test vectors pass with this change
I think the plan of action here SHOULD be some combination of 1) editing key manifests going forward, so the key name of a public/private key pair is the same; 2) add a "legacy" check in TestVectors to align the key name of any keys with names "rsa-4096-private" and "rsa-4096-public"
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.
Is this plan of action going to happen here or is this happening somewhere else?
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.
So we generate with master key, and then decrypt with JS and master key.
How do we test keyring? Does the master key target do both?
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.
Should this be in the MPL Test vectors project?
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.
If it isn't already, I think that's a good idea
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.
Chatted with Jose, it's a good idea to put this in the test vector framework.
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.
Can I resolve this? If this is done, just resolve the conversation plz :)
) | ||
) | ||
|
||
# Weird hack #2: |
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.
I'm not sure I'm following, I follow up.
This sounds like these hacks are fighting. The name of the key and the name of the key info are not the same thing.
That is correct for Python <3.11.
|
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 good! So many commits!
@@ -40,7 +40,8 @@ def get_requirements(): | |||
license="Apache License 2.0", | |||
install_requires=get_requirements(), | |||
# pylint: disable=fixme | |||
# TODO: Point at MPL main branch once Python MPL is merged into main. | |||
# TODO-MPL: Point at PyPI once MPL is released. | |||
# This blocks releasing ESDK-Python MPL integration. |
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.
Just wondering do we have a way to enforce this?
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.
Yes! PyPI will not let you publish a package that uses GitHub directly. We MUST refer to the published MPL to publish the new ESDK-Python.
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.
@patch("aws_encryption_sdk.streaming_client.derive_data_encryption_key") | ||
@patch("aws_encryption_sdk.streaming_client.DecryptionMaterialsRequest") | ||
@patch("aws_encryption_sdk.streaming_client.Verifier") | ||
# Given: no MPL | ||
@pytest.mark.skipif(HAS_MPL, reason="Test should only be executed without MPL in installation") | ||
def test_GIVEN_decrypt_config_has_ec_WHEN_read_header_THEN_calls_decrypt_materials_with_reproduced_ec( | ||
self, |
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.
Just wondering why we are deleting these?
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.
This might be a diff issue... let me double check
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.
Ah! This was a merge conflict issue. I committed this test when I shouldn't have.
The behavior from this test is no longer valid.
This test would assert that encryption context on decrypt works for native (ESDK-Python) CMMs.
We decided that encryption context on decrypt would not be supported in this thread.
The new behavior validating encryption context on decrypt raises an exception is present here.
Issue #, if available:
Description of changes:
awses_local
; this test is now redundant by the additions above.Out of Scope
By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.
Check any applicable: