bug: Can't have 2 Obfuscated Packages

[cat-loaf]

🐞 Bug Description

When you obfuscate two packages, and try to import both packages, one of the packages fails as codeenimga generates a .so file (Shared Object), and this .so file is generated per obfuscation.

The codeenigma runtime is different per package, and causes one of the packages to fail on import.

🔍 Steps to Reproduce

1. Obfuscate & build package A
2. Obfuscate & build package B
3. Install both packages (A and B) to an environment
4. Attempt to import both packages

import A
import B

📝 Additional Context

Currently, the work around is that I package A & B together, and obfuscate them together.
This won't work if someone wants to import multiple obfuscated packages.

✅ Proposed Solution

Generate a unique runtime module name for each obfuscation build (e.g. codeenigma_runtime_<uid>)
Embed that name into the obfuscated package, and build the C-extension with that name.

This ensures each obfuscated package installs and imports a differently-named .so/.pyd, and therefore exports a unique PyInit_<name> symbol, meaning no shared object collisions.

[ThomasJRyan]

Going a bit further, the existence of the codeenigma_runtime itself is a bit of an issue. If I want to release my package I seemingly need to also release the corresponding codeenigma_runtime as well. I'm thinking it would be better to have this built into the obfuscated package instead, allowing for a single package to be released and removing the limitation described in this issue

[KrishnanSG]

Sorry @cat-loaf and @ThomasJRyan for a late reply.

Yep this is a known limitation. Even I'm facing challenges with it now at work when I have to package 2 modules together. I wanted to enhance it further but didn't get time 😕

@cat-loaf your suggestion is good we can have different package ids then there is no conflict and it will all work good.

@ThomasJRyan curious to understand more on how we will further create this into a single package.

[ThomasJRyan]

I'll admit, I'm not at all sure how it could be gone about. You're definitely smarter than me here. I'll see if I can play around with it and get you more than a "do it this way!!!!".

I envision it as living inside the package as a module. Something like if my package was called foo then there would be a foo.code_enigma module that unpacks everything on import. It definitely trivializes the problem at hand though.

[KrishnanSG]

@ThomasJRyan
I will also explore this coz if we make it all a single package then it's easy to distribute and doesn't need 2 packages to be shared/published.

[KrishnanSG]

@ThomasJRyan & @cat-loaf
I'm really curious and would love to hear, how you guys came across my repo and how you guys are using it 😄

[ThomasJRyan]

@ThomasJRyan & @cat-loaf
I'm really curious and would love to hear, how you guys came across my repo and how you guys are using it 😄

I came across it looking for an alternative to Cython for code obfuscation. Needed something that was easy to use and complied with some form of standards.

Currently I'm unable to use this project due to the extra package that gets generated. I've got several packages that need to be obfuscated and installed together so only being able to do one at a time is a crippling limitation.