-
Notifications
You must be signed in to change notification settings - Fork 86
TypeError: unhashable type: 'EncryptedDataKey' - possible incompatibility with attrs-17.1.0 #2
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
Comments
I was actually just reading through the changelog for attrs 17.1.0 the other day, and yes, I believe your conclusion is correct. Attrs called this out as a breaking change in 17.1.0. For the moment, stick with 16.3.0. I'll take a look and run through our tests to see what we need to update to work with 17.1.0. |
Great, thanks very much, that makes sense. The SDK is working perfectly with 16.3.0 and I'm very happy with the functionality, it's turning out to be really useful! Cheers |
Great to hear! |
The immediate effect of this is addressed in: Fix onto 16.3.0 in setup.py: ec0c80a The next release will bump up to ==17.1.0 with all necessary corresponding changes. |
Hi
I'm getting the above error when trying to encrypt using
aws_encryption_sdk.encrypt()
as per the README.md instructions here at this location:I'm using Python 2.7.4 with
aws-encryption-sdk-1.2.0
andattrs-17.1.0
(which I think is the cause of the problem). Installation of the SDK looked fine, and the dependencies installed fine too.The
__hash__
method on encrypted_key isNone
, so it's unable to add it to the set being returned byprepare_data_keys()
.When I edit
aws_encryption_sdk/structures.py
and addfrozen=True
to the@attr.s()
decoration onclass MasterKeyInfo(object)
andclass EncryptedDataKey(object)
, the objects become hashable courtesy ofattrs
, and it seems to work OK.The changes to
attrs
could be the problem here, looking at commits since 16.3.0, there are a few relating to frozen classes and hashing behaviour.Reverting to
attrs-16.3.0
works fine, which would seem to confirm this.I'm using a fresh CMK loaded into a
KMSMasterKeyProvider
as per the instructions:The
EncryptedDataKey encrypted_key
that's obtained and returned looks OK and is:Please let me know if you need any further information?
Thanks
Richard
The text was updated successfully, but these errors were encountered: