Michael Zimmermann schrieb:
Well, after a bit of trial and error I understand the bit about
building a signed interpreter (Actually, this is working as I want it
to work).
Currently I use my default installation that has QT and PyQT
installed. With this setup anyone would be able to use the existing
libraries with a generic python interpreter and bypass our signed
interpreter. Not good.
What I think about doing is:
- Compile the pyQT modules statically into python
Why do you want to do that? By protecting PyQt from beeing used by a
generic interpreter, there is no need to build PyQt statically linked
into Python.
Just distribute the protected PyQt dynamic loadable modules together
with your application. I can't see any advantanges with a statically
linked PyQt. You end up with huge executables, containing builtin
modules that your applications may never use (e.g. qttable, qtxml, qtsql
...).
- Generate a singed interpreter for our applicaton
- Distribute the signed interpreter + any additional scripts + the
python libs (including pyQT)
But here are the questions:
How about QT?
Imho I do need a QT library before I can build pyQT. Then, is it
necessary to patch the code of QT to make it VendorId-aware? If so,
where? Or how should I deploy the QT libs?
No. Qt has nothing to do with VendorID.
The VendorID code is a kind of contract between signed python
interpreters and protected extension modules (not only releated to PyQt):
"Tell me (the module) who you (the interpreter) are, and if I can accept
you, I will allow you to use me."
There is no need to do anything with Qt. Just distribute the shared Qt
library you have built together with your application and the protected
PyQt modules.
How about PyQT?
Is it enough if I configure PyQT with the -i command line switch to
make it vendorId aware?
Yes. The -i command line switch is enough to protect PyQt from beeing
used by a generic interpreter.
Note, that there is no need to build two versions of PyQt (protected and
unprotected), you only need to build a protected PyQt with -i. Because
the VendorID package creates the dynamic loadable module vendorid.pyd,
you and only you can use your PyQt modules with the generic interpreter.
The signed interpreter and qt.pyd are linked with the static library
vendorid.lib. If you do not distribute vendorid.pyd and vendorid.lib
(you should never do this), nobody else can use your PyQt with a generic
interpreter or can create a new signed interpreter.
Once again our objective is not to make a self-contained .exe but
rather a solution, that leaves some of our code exposed to
modifcations ....
When using SIB, you decide which modules/packages should be frozen into
the executable and which modules/packages should be left external. At
minimum, you only freeze the applications main script, at maximum, you
put all modules/packages of your application into the resulting
executable. When you put only your main script into the executable, you
should by sure, that this script contains a reasonable amount of
application specific code. Something like "import foo; foo.run()" is
definitely too generic, because someone could replace your foo.py with a
completey different foo.py starting application development with your
signed interpreter.
Note, that you can still use py2exe, to build a self containing
application package with all dependent modules and libraries. You just
have to replace the executable created by py2exe with an executable
created by SIB.
If you think, it would be a good idea to modify py2exe or cx_Freeze to
create signed interpreters for you: forget it. Both tools rely on
prebuilt generic script starter executables and attach the applications
main script to this executable using various techniques. Everybody can
replace the attached main script with another one using the same
technique. You definitely need a compile/link cycle.
---
If you think, you miss something in the documentation of VendorID (I'm
sure you have read the docs at least twice :-) ), please let me know.
Ulli
_______________________________________________
PyKDE mailing list PyKDE@mats.imk.fraunhofer.de
http://mats.imk.fraunhofer.de/mailman/listinfo/pykde
