Replies: 1 comment 1 reply
-
I'm not sure Pyodide is very different from Python running in a classical environment in this respect. The easiest choice is probably to compile sensitive code (e.g. with Cython) which would also work with Pyodode.
I'm not sure protecting them more would help much. With the browser debugger it would be possible to access the decrypted information at runtime. Maybe there are some smarter things to try (e.g. writing some custom emscripten FS implementation) but if it's just a module or two compiling might be easier. |
Beta Was this translation helpful? Give feedback.
1 reply
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
-
https://pyoxidizer.readthedocs.io/en/stable/comparisons.html
There has been many attempts to package Python code mainly in the purpose of protecting the codebase. PyInstaller encrypts .py files using AES256 and hides the key in the executable, making reverse engineering non-trivial. Cython and Nuitka literally compiles Python making code retrieval non-trivial as well. PyOxidizer is in the middle, packing the code into a non-trivial executable.
This Documentation seems to only zip the code and produces no additional protection.
What would be a good way to offer code protection (as much as compiled languages) into Pyodide packages in order to make code retrieval from the .js and .data files non-trivial (assuming This is protective enough)?
Beta Was this translation helpful? Give feedback.
All reactions