David Scott Williams
xiarcel at prodigy.net
Thu Jul 3 13:04:49 CEST 2003
It's been awhile since I've been on the python list... but I'll take a
whack at this:
> Re: Python executables?
> Geoff Howland <ghowland at lupineNO.SPAMgames.com>
> Thu, 03 Jul 2003 06:41:18 GMT
> python-list at python.org
>On 27 Jun 2003 09:24:22 +0950, Ben Finney
><bignose-hates-spam at and-zip-does-too.com.au> wrote:
>>>This solves the problem of giving python programs to users who don't
>>>have python but doesn't solve the problem of the source "secrecy"
>>Wrong problem. If you want to hide your source code from your users,
>>don't expect help from free software programmers.
>I thought about this for a few days before responding (and Im sure I
>did a few other things too ;) ), but I wanted to comment on this.
>I think everyone that uses Python wants it to gain acceptance for the
>great language that it is. I believe that stating an attitude in this
>way is pretty counter productive in gaining any kind of wide-spread
Unfortunately, though, I don't think you get any more tread coming to
the Open Source developers and asking them how to hide your bits... This
is your issue, reversed.
>Most of the replies to this request didn't mention the concept of NOT
>protecting the software, but 2 did to different degrees. As someone
>who uses and like open source software, and is slowly starting to
>release some things as open source, and ALSO someone who sells
>software and will continue in the future to sell software, I can say
>that nothing turns me off more to a community than being told what my
>goals should be.
I think if your goals are un-reasonable, asking a hammer salesman how
best to use his tool to screw something into drywall is again, similary,
counter-productive. Scripting languages are hard to obfuscate, if not
damned near impossible. Even Java byte-code can be decompiled back to
fairly decent looking source...
>I can understand wanting everything to be open, but thats not reality
>and it never will be.
I, personally, don't disagree with this.
> Some people will always want things
>proprietary, and they will only work within systems that allow that.
>I think to be truly successful, systems will have to allow for this
>and make it easy to do.
>Currently Python does not make this REALLY easy to do, and in the
>privacy portion, I believe its not even possible. This was a big
>concern for me when I released my last for-sale software, but I just
>decided I didn't care that much, and I love working in Python.
Often times, I think, Python caters to the developers that develop
95-98% of the software --in house software where source code access
isn't a problem either way... It is good for mock-ups, for getting
something structured and OO, and for writing software that otherwise
doesn't yield you revenue (install, config scripts, for example)... It
is great for other software too... and some companies make money selling
support for the source, many users are not hackers, even unix/linux
>Some people will care enough, and will avoid Python because the
>ability to protect their end results aren't there.
This loss is unfortunate, perhaps someday they will see that software
really isn't a commodity, but a service.
>So far, the only semi-workable way to do this would be something like:
>- Build a C program that embeds Python.
>- Encrypt all the Python script/bytecode files.
>- On runtime, decrypt the files and then execute.
>- Change the bytecode values in the Python source, and include your
>new Python with different bytecode values.
>I tried this last thing just to see if it would work, and I got some
>problems compiling initially, so just gave up, but I think in theory
>it should work.
>Ignoring the Optional portion, this semi-solution is not actually very
>secure. It does however move the problem into having to decompile a C
>program, and then get it to decrypt the Python files. Then the normal
>Python bytecode -> source. It means any cracker will have to know
>something about both C and Python to do it, so a bit more barrier to
>entry. It also means that in the US, the (vile and despicable, but
>present) DMCA laws will make it a much more severe crime because
>"cryptography reverse engineering" needed to be applied, and may at
>least reduce corporations from doing this for fear of
>lawsuits/criminal charges if they are exposed.
Perhaps you could write an open source python code obfuscator? Or
write it in C and make it closed source?
>Anyway, this is a good bit of work and not a great solution, but is
>there anything else? If Python is to have avenues of support in all
>walks of the software industry, will something like this be required?
I still think that python is often used as glue... the easy and
straightforward style add value to the remaining (if obfuscated) bits...
>>From what I understand, there are also very good Java decompilers, but
>no one seems to complain about Java's lack of security. Perhaps it is
>because it is seen as something that is really "compiled" while
>Python's loose compilation seems more whimsicle.
mentioned this above myself... There are obfuscators for java...but if
someone wants it bad enough, they can get your source, or something
reasonably close... in almost ANY language.
>I think Python faces a lot of different public relations problems, and
>just thought I'd pipe up about one that I have looked at myself, and
>that I think most people coming into the Python world are faced with
>and have to decide whether to ignore or not.
xiarcel at prodigy.net
(and current obsession)
>Dustyscript: Programming for Children<
||*Other projects that I head up*||
>The xTable Project<<
>Moonroof, a Java desktop<
||**Projects that I am dedicated to (but not in charge of)*||
>Grapevine p2p network<
"The Java Port"
"When I think back on all the crap I learned in High School...
it's a wonder I can think at all..."
-Paul Simon, "Kodachrome"
"...I took the road less travelled by, and that has made all the difference.."
"Man is the only animal that blushes... or needs to"
More information about the Python-list