how to avoid uploading .py source files to shared hosting server
ydjango
I am developing on python 2.4.4 and django svn branch.
I want to upload to webfaction which if I ssh and run python is python
2.4.3.
Application installed is Django trunk/mod python 3.3.1/ python 2.5
I want to upload only .pyc and no source files. Whats the best way to
make sure my .pyc works there.
thanks
Ashish
jonknee
> make sure my .pyc works there.
then delete the .py files. That way you're sure that the .pyc files
are compatible. But unless you really need to get rid of the .py
files, you should leave them be.
ydjango
implementations which I do not want to expose.
Hence I do not want to upload .py source files
Is rewriting that business logic in a compiled langauge only way out?
how do I call it from python, Using web services?
Ashish
Gabriel
> I have propriety commercial code and some formula/ algo
> implementations which I do not want to expose.
> Hence I do not want to upload .py source files
>
> Is rewriting that business logic in a compiled langauge only way out?
> how do I call it from python, Using web services?
>
No no, I have come across a number of ways of obfuscating Python code, just have
a search. Using the .pyc files provides weaker obfuscation which may or may not
be enough. Can you not simply do something using rsync:
rsync -vrlptzH --delete --progress /home/user/*.pyc \
us...@example.com:/home/user/www
Can't remember what exactly to get rsync to only copy pyc files but check the
man pages. Otherwise you could look at scp.
James Bennett
> I have propriety commercial code and some formula/ algo
> implementations which I do not want to expose.
> Hence I do not want to upload .py source files
If your host's setup would allow other users to view this code, you
have much larger and much more dangerous security problems to worry
about (since, for example, that would mean they could also see
sensitive passwords in configuration files).
--
"Bureaucrat Conrad, you are technically correct -- the best kind of correct."
ydjango
settings.py
On May 16, 3:20 am, "James Bennett" <ubernost...@gmail.com> wrote:
James Bennett
> Yes, that was another thing on my mind, how to encrypt password in
> settings.py
You don't. I think either you misunderstand how shared hosting works,
or you have an extremely bad host.
Julien
hosting service: make sure permissions are set correctly (e.g. don't
give any right to "others" to your home directory), and use a complex
password for your account (using numbers, a mix or lowercased and
uppercased characters, et no word from the dictionary).
Following that kind of basic precautions I'd put all my trust in hosts
like webfaction.
On May 17, 12:16 am, "James Bennett" <ubernost...@gmail.com> wrote:
jonknee
> I have propriety commercial code and some formula/ algo
> implementations which I do not want to expose.
> Hence I do not want to upload .py source files
your files. If you believe your host is going to snoop in your account
and steal your algorithm and sell it to your competitors, you
definitely need a new host.
ydjango
outsider or may be an rougue hosting provider employee or contractor,
to easily get access to all the information - data and code.
I would have thought by this time easy solutions for this issue would
have been found.
I know I am a bit paranoid when it comes to security, probably becuase
of my background in financial industry.
I also do understand at some point you need to trust some one and that
a hosting provider will not do such a thing as stealing your code.
and likelyhood of such a break-in happening is very rare. ( I have no
ssn or credit card info, so why would anyone bother to break in.)
Also, I read somewhere that google does not use python for its core
busines applications. It uses it as glue langauage and for internal
operations automation mostly. Just a random thought.
thanks
Ashish
jonknee
> I do not want to make it easy for some one who breaks in , either a
> outsider or may be an rougue hosting provider employee or contractor,
> to easily get access to all the information - data and code.
>
limiting server access to your IP address is a good start. But if
someone gets into your server they will be able to access your code.
It doesn't matter if it's .py or .pyc--if it can be executed it can be
deconstructed by a motivated attacker. This isn't the fault of Python,
it's the same in other languages. You can obfuscate your code, but
it's still security through obscurity.
> Also, I read somewhere that google does not use python for its core
> busines applications. It uses it as glue langauage and for internal
> operations automation mostly. Just a random thought.
plenty of public facing services using Python, including Groups and
Code. Google does a ton in Java (like Gmail) and that's really easy to
decompile. Google protects access to its code and as such a .py file
is just as secure as anything else.
James Bennett
> I do not want to make it easy for some one who breaks in , either a
> outsider or may be an rougue hosting provider employee or contractor,
> to easily get access to all the information - data and code.
Again: if this is your worry, you have bigger problems. Allow me to
suggest an alternate method:
(satire begins here, for the humor-impaired)
1. Physically obtain the server upon which the code is stored. Write
random data to the relevant sectors of the hard drive seven times
over, then write zeroes to it seven times over, then write random data
again.
2. Physically destroy the hard drive. Sledgehammers are good for this.
3. Place the shards of the hard drive into a vat of highly caustic acid.
4. Once the shards have dissolved, burn the resulting acidic liquid.
Be sure to capture the smoke.
5. Cool the smoke until it turns back to ash. Mix the ash into the
center of a reinforced concrete slab, at least 27 cubic feet in
volume.
6. If you have access to sufficient technology, launch the concrete
slab into space, on a course to collide with the Sun or (better) with
any singularity which happens to be nearby. The singularity is best
because -- even though it may not guarantee destruction of the
information -- the subjective time to observe the rocket crossing the
event horizon, from the frame of reference of a person some distance
from it, will be effectively infinite, causing most attackers to give
up.
7. If you do not have access to sufficient technology, have the
concrete slab stored in a nuclear-hardened bunker, with no Internet
connection, in a room using biometric identification keyed to
yourself, and with the whole complex guarded 24/7 by US Navy SEALs.
Maintain this watch until the technology available to complete step
(6) becomes available to you.
Once you've completed this process, your application code will be
safe, for a reasonable value of "safe".
(satire ends here)
Or you could just find a host who properly sets up file permissions so
that random people can't access your application code. Unless you own
and personally supervise all of the following you will be susceptible
to rogue employees: the server, the rack in which it's located and the
datacenter in which the rack is found. Many people do not find that
the perceived security gains of doing so outweigh the financial and
maintenance drawbacks. YMMV.
Steven Armstrong
James, your the man :-)
I would have suggested:
Book a trip to the himalaya (well maybe after china has stopped being a
PITA). March all the way to the top (make sure no CIA satellites are
watching you). Dig a deep hole, say 100 foot deep, then barry your code
in the hole. Then fill it up (again, check that those evil nasty
satellites aren't watching), and go back home with the good feeling that
your code, that nobody else on this planet could have written in such
an elegant, perfect way will never be found and used by anybody.
;-)
ydjango
your upcoming book. Hopefully it has the same humor.
On point 7) what about a navy seal who want to retire and start a
software business, how do I design a selection system to avoid those.
I do not want future competitor snooping around my code.
I would have preferred Himalaya, But it is between india and china.
Cannot trust those guys either. They are taking away all our jobs and
now code too. No way.
thanks
Ashish
On May 16, 11:11 am, "James Bennett" <ubernost...@gmail.com> wrote: