Obscuring Python source from end users

[alister]

On Mon, 29 Sep 2014 00:36:47 -0700, norman.ives wrote:

> Hello list
> 
> Python 3.4 applies.
> 
> I have a project that involves distributing Python code to users in an
> organisation. Users do not interact directly with the Python code; they
> only know this project as an Excel add-in.
> 
> Now, internal audit takes exception in some cases if users are able to
> see the source code.
> 
> So I'm wondering if anyone has clever suggestions in this regard...
> 
> My current plan is to modify the bdist_wheel setuptools extension so
> that it can produce distributions with only the .pyc files, laid out so
> that they will be importable in the normal way. This will be sufficient
> to satisfy internal audit, and will not negatively impact our users.
> 
> However there are obvious downsides, including the overhead of
> maintaining separate wheels for different architectures and (in the
> future) Python versions. Not to mention that this plan seems to go
> against the grain of how Python wants to use byte code files...
> 
> Is there a better solution?

For an internal app. I would suggest it is only necessary to protect user-
names & passwords to back end services (databases etc.).

storing these in a separate file in an encrypted format should be enough 
to discourage internal users from digging deeper.

This will not stop a determined hacker but neither will any other forms 
of obfuscation.



-- 
new, adj.:
	Different color from previous model.