Path: csiph.com!v102.xanadu-bbs.net!xanadu-bbs.net!feeder.erje.net!eu.feeder.erje.net!xlned.com!feeder3.xlned.com!newsfeed.xs4all.nl!newsfeed1.news.xs4all.nl!xs4all!newsgate.cistron.nl!newsgate.news.xs4all.nl!post.news.xs4all.nl!not-for-mail Return-Path: X-Original-To: python-list@python.org Delivered-To: python-list@mail.python.org X-Spam-Status: OK 0.006 X-Spam-Evidence: '*H*': 0.99; '*S*': 0.00; 'scripts': 0.03; 'interpreter': 0.05; 'output': 0.05; 'applicable,': 0.07; 'subject:code': 0.07; 'imported': 0.09; 'parsing': 0.09; 'python': 0.11; 'bug': 0.12; 'suggest': 0.14; "wouldn't": 0.14; '.py': 0.16; 'codebases.': 0.16; 'command-line': 0.16; 'extension.': 0.16; 'insisted': 0.16; 'parser.': 0.16; 'subject:possible': 0.16; 'trivially': 0.16; 'unambiguous': 0.16; 'subject:python': 0.16; 'prevent': 0.16; 'all.': 0.16; 'wrote:': 0.18; 'code.': 0.18; 'pointed': 0.19; 'email addr:gmail.com>': 0.22; 'print': 0.22; 'adds': 0.24; 'of.': 0.24; 'subject: .': 0.24; "i've": 0.25; 'source': 0.25; 'developers': 0.25; '>': 0.26; 'compiled': 0.26; 'extension': 0.26; 'purposes': 0.26; 'least': 0.26; '(for': 0.26; 'header:In-Reply-To:1': 0.27; 'to:2**1': 0.27; '(this': 0.29; 'tim': 0.29; "doesn't": 0.30; 'strongly': 0.30; 'message- id:@mail.gmail.com': 0.30; "i'm": 0.30; 'code': 0.31; 'getting': 0.31; 'remotely': 0.31; 'yesterday': 0.31; 'compatible': 0.32; '(e.g.': 0.33; 'to:name:python-list': 0.33; 'something': 0.35; 'but': 0.35; 'received:google.com': 0.35; 'there': 0.35; 'version': 0.36; 'really': 0.36; 'edge': 0.36; 'largely': 0.36; 'done': 0.36; 'doing': 0.36; 'useful': 0.36; 'possible': 0.36; 'subject:?': 0.36; 'january': 0.37; 'e.g.': 0.38; 'needed': 0.38; 'to:addr:python-list': 0.38; 'files': 0.38; 'does': 0.39; 'help,': 0.39; 'hosted': 0.39; 'obtain': 0.39; 'to:addr:python.org': 0.39; 'skip:p 20': 0.39; 'how': 0.40; 'ensure': 0.60; 'easy': 0.60; 'truly': 0.60; 'most': 0.60; "you're": 0.61; 'offer': 0.62; 'information': 0.63; 'become': 0.64; 'to:addr:gmail.com': 0.65; 'corporate': 0.67; 'sam': 0.68; 'manner': 0.72; 'secret': 0.74; 'protect': 0.79; 'bare': 0.84; 'compiling': 0.84; 'extensions.': 0.84; 'snatch': 0.84; 'subject:source': 0.84; 'absolutely': 0.87; 'insane': 0.93 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=5/ACJdAmVT6Z0WWPnMxhG7oJv3jjivx8dSggDfe+H1w=; b=jMn4Eo0NMFHQ3m7lmPL2Cw91A/P72V9EnlFX4Up9exYgqatJfRkmLIglTXv32DKona KDR+XdK2AW7hY/ahR00vaN9vrehoeKQjTaIpvrAxq7G7a5wAv1uCja1C3n8OFYqVVViy SF/2jwOxaCpFdsqxcoOAV8hFKHPoNhz9Kpytj0svcURWd3TvCDQAAj7pfSYW9wyruL+q di7c6hvRAyk8d02kFbxuRRHmCaZqh2lhn5OEOkmHI/lPzRz78OMiTdx4i7zA3TOCIhBg f/b/v0w+lPsmAYkUcmOaPimN+Ch8r1bLLJMTZeamuxMYqEjQyx8izz7/dBhpHLsZDGUn s3NA== MIME-Version: 1.0 X-Received: by 10.60.67.105 with SMTP id m9mr3605072oet.58.1389996162967; Fri, 17 Jan 2014 14:02:42 -0800 (PST) In-Reply-To: References: <7bf45fc1-e1c4-44f2-812c-e11ffa2c8ef3@googlegroups.com> Date: Sat, 18 Jan 2014 09:02:42 +1100 Subject: Re: Is it possible to protect python source code by compiling it to .pyc or .pyo? From: Tim Delaney To: Sam , python-list Content-Type: multipart/alternative; boundary=001a11c301fc886f5804f031b35a X-BeenThere: python-list@python.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion list for the Python programming language List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Newsgroups: comp.lang.python Message-ID: Lines: 102 NNTP-Posting-Host: 2001:888:2000:d::a6 X-Trace: 1389996172 news.xs4all.nl 2970 [2001:888:2000:d::a6]:42389 X-Complaints-To: abuse@xs4all.nl Xref: csiph.com comp.lang.python:64198 --001a11c301fc886f5804f031b35a Content-Type: text/plain; charset=UTF-8 On 18 January 2014 08:31, Joshua Landau wrote: > On 17 January 2014 00:58, Sam wrote: > > I would like to protect my python source code. It need not be foolproof > as long as it adds inconvenience to pirates. > > > > Is it possible to protect python source code by compiling it to .pyc or > .pyo? Does .pyo offer better protection? > > If you're worried about something akin to corporate espionage or > some-such, I don't know of a better way than ShedSkin or Cython. Both > of those will be far harder to snatch the source of. Cython will be > particularly easy to use as it is largely compatible with Python > codebases. > Indeed - I've only had one time someone absolutely insisted that this be done (for trade secret reasons - there needed to be a good-faith attempt to prevent others from trivially getting the source). I pointed them at Pyrex (this was before Cython, or at least before it was dominant). They fully understood that it wouldn't stop a determined attacker - this was a place where a large number of the developers were used to working on bare metal. If you're going to do this, I strongly suggest only using Cython on code that needs to be obscured (and if applicable, performance-critical sections). I'm currently working with a system which works this way - edge scripts in uncompiled .py files, and inner code as compiled extensions. The .py files have been really useful for interoperability purposes e.g. I was able to verify yesterday that one of the scripts had a bug in its command-line parsing and I wasn't going insane after all. Also, remember that any extension can be imported and poked at (e.g. in the interactive interpreter). You'd be surprised just how much information you can get that way just using help, dir, print and some experimentation. The output I was parsing from one of the scripts was ambiguous, and it was one where most of the work was done in an extension. I was able to poke around using the interactive interpreter understand what it was doing and obtain the data in an unambiguous manner to verify against my parser. The only way to truly protect code is to not ship any version of it (compiled or otherwise), but have the important parts hosted remotely under your control (and do your best to ensure it doesn't become compromised). Tim Delaney --001a11c301fc886f5804f031b35a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On 1= 8 January 2014 08:31, Joshua Landau <joshua@landau.ws> wrote:=
On 17 January 2014 00:58, Sam <lightaiyee@gmail.com> wrote:
> I would like to protect my python source code. It need not be foolproo= f as long as it adds inconvenience to pirates.
>
> Is it possible to protect python source code by compiling it to .pyc o= r .pyo? Does .pyo offer better protection?

If you're worried about something akin to corporate espionage or<= br> some-such, I don't know of a better way than ShedSkin or Cython. Both of those will be far harder to snatch the source of. Cython will be
particularly easy to use as it is largely compatible with Python
codebases.

Indeed - I've only had o= ne time someone absolutely insisted that this be done (for trade secret rea= sons - there needed to be a good-faith attempt to prevent others from trivi= ally getting the source). I pointed them at Pyrex (this was before Cython, = or at least before it was dominant). They fully understood that it wouldn&#= 39;t stop a determined attacker - this was a place where a large number of = the developers were used to working on bare metal.

If you're going to do this, I strongly suggest only= using Cython on code that needs to be obscured (and if applicable, perform= ance-critical sections). I'm currently working with a system which work= s this way - edge scripts in uncompiled .py files, and inner code as compil= ed extensions. The .py files have been really useful for interoperability p= urposes e.g. I was able to verify yesterday that one of the scripts had a b= ug in its command-line parsing and I wasn't going insane after all.

Also, remember that any extension can be imported=C2=A0= and poked at=C2=A0(e.g. in the interactive interpreter). You'd be surpr= ised just how much information you can get that way just using help, dir, p= rint and some experimentation. The output I was parsing from one of the scr= ipts was ambiguous, and it was one where most of the work was done in an ex= tension. I was able to poke around using the interactive interpreter unders= tand what it was doing and obtain the data in an unambiguous manner to veri= fy against my parser.

The only way to truly protect code is to not ship any v= ersion of it (compiled or otherwise), but have the important parts hosted r= emotely under your control (and do your best to ensure it doesn't becom= e compromised).

Tim Delaney=C2=A0
--001a11c301fc886f5804f031b35a--