Look up encryption keys using file contents, not paths (#6)

[mkai]

This is an attempt at solving issue #6 where the encryption key lookup would only work when the code was executed from a specific path.

Instead of using relative file system paths, this change computes a hash of the encrypted file's contents and stores the encryption key with it. Upon import, the same hash is produced again to find the right decryption key for the file in question.

[theonewolf]

I felt this code looked pretty good @mkai on my first read through.

I think we need to bump major version as I don't think this is backwards compatible.

I'll test this later today or tomorrow and merge.

[mkai]

I think the only way we could make it backwards-compatible is if we made the content-based key storage and lookup optional.

Admittedly, the data structure that comes out of encrypt_path doesn't look as straightforward as before from a user's point of view with the hashes instead of the relative file paths. This is a downside to this change.

The upside is, obviously, that the decryption works as expected regardless of where I run the code from. Previously, once I placed the code somewhere else, it would no longer decrypt even though the keys were present.

I could think of one change to make the key structure look less obscure (although we would lose the deduplication aspect you mentioned). We could store both the relative path and the content hash:

from pyce import encrypt_path
encrypt_path('pyce/hello.pyc')
[('pyce/hello.pyce:da78a5bfe655d01334d7121dc0f021de870dc11515424f528045eb5f29098504', 'd11d969ab1d345df86f4180db549f5ffc400da10d03d43e1fa93eae373199dae')]

The advantage to this is that it would be more user-friendly. But it would still be backwards-incompatible and from a purely technical point it has only drawbacks.

I'm not advocating for this change, I think it's a design decision for you to make.