search

wbond / oscrypto

Compiler-free Python crypto library backed by the OS, supporting CPython and PyPy
MIT License
318 stars 71 forks source link

Add support for custom backend. #26

Closed pbryan closed 6 years ago

pbryan commented 6 years ago

Did my best to maintain your style conventions. If you'd be willing to forego 2.6 compatibility, could easily make imports programmatic.

wbond commented 6 years ago

Unfortunately I'm not willing to drop 2.6 at this point, since this project is used in Package Control, which still supports Sublime Text 2, which uses Python 2.6. From having futzed around with import stuff for the test suite and dev/deps.py, I think it shouldn't be too bad to handle.

I haven't had time to look at this in-depth, but I scanned over it the other day and it seems to be a pretty reasonable way to inject alternate implementations of some/all functions.

wbond commented 6 years ago

I rebased your changes on master and tried to push to your branch but it closed this PR. Weird behavior by GitHub. Anyway, check out https://github.com/wbond/oscrypto/tree/custom-backend and see if that works on your end? Unfortunately GitHub won't let me re-open the PR since it says there are no changes.

We should probably find a way to test it with a Mock custom backend of some sort.

pbryan commented 6 years ago

Looks good. In my testing, I simply mocked the _openssl backend as the custom backend package. In my work on PKCS #11, I've copied the _openssl backend, and replaced only the functions that I'm using with the hardware security module.

wbond commented 6 years ago

If you have an ideas about how to make selectively replacing functions/objects easier in a given backend, it would be great if you could open an issue, just so anyone can use it as a reference

pbryan commented 6 years ago

Alright, let me think more about that. Time permitting, I'm planning on having a full PKCS #11 backend, so it won't be selective. This opens up the door for creating a pure Python backend too.

pbryan commented 6 years ago

I just tried your branch, and it seems broken since the introduction of imp to attempt to find modules. As far as I know, find_module can't resolve at the package level. Any chance of reverting that change? Alternative will be I'll keep running on my own branch and try to keep it in lock step with yours.