On Dec 8, 2004, at 8:35, Phillip J. Eby wrote:
At 11:50 PM 12/7/04 -0500, Bob Ippolito wrote:On Dec 7, 2004, at 10:40 PM, Phillip J. Eby wrote:
Also, if you allow extraction of C extension modules, you'll probably also have to allow extraction of dependent dlls and whatnot.. which is a real mess. For dependent dynamic libraries on Darwin, this is a *real* mess, because the runtime linker is only affected by environment variables at process startup time. I can only think of two solutions to this for Darwin:
(a) build an executable bundle on and execve it on process startup, drop the dependent libraries inside that executable bundle
(b) have some drop location for dependent libraries and C extensions and rewrite the load commands in them before loading (which may fail if there isn't enough wiggle room in the header)
With regard to 'b', I'm not quite sure I understand about the rewriting load commands. Are you saying that on Darwin, you have no LD_LIBRARY_PATH? Because, wouldn't it suffice for the application to have that defined when it starts, and install the libraries on that path? What am I missing, here?
Load commands (runtime dependencies between Mach-O files) have full paths embedded in them, not just names, so that is why header rewriting is useful. If these load commands start with "@executable_path/", then the first place the library is looked for will be relative to the executable, which makes (a) possible and is what py2app already does when you start including dependencies.
IOW, if you have a directory set up on LD_LIBRARY_PATH or its equivalent, can't you just dump the libraries and C extensions there?
Darwin has a pair of environment variables that are sort-of equivalent to LD_LIBRARY_PATH, however, their values are cached by the runtime linker (dyld) as soon as a process starts. Since a new process has to be started to use these from this environment anyway, (a) is the better option because setting these environment variables have panDYLD_FRAMEWORK_PATH or DYLD_LIBRARY_PATH has penalties associated with it.
* Update URL (for obtaining the "latest" version of the plugin)
How about some kind of public key as well, so that if you visit the update URL you will know if the new package was provided by the same author or not?
Sounds like a cool idea, although I'm not sure how you could sign a zipfile from inside the zipfile. Unless the idea is to stick some extra data on the front or back?
How about we include a manifest file that includes filename, size, and a hash of the file's contents, and has the author's public key in there somewhere at the top or bottom. A second file, or a SMIME or PGP style wrapper around the manifest file, will contain the hash of the manifest file that is signed by the author's private key.
Obviously this doesn't do you much good until you download an upgrade, but when you do download an upgrade, you can verify that the author is the same as what you already have and its contents have not been tampered with. Verifying the first time you download something is not really possible anyway, because you don't already "know" the author, so you would need some out of band mechanism.
-bob
_______________________________________________ Distutils-SIG maillist - [EMAIL PROTECTED] http://mail.python.org/mailman/listinfo/distutils-sig
