[Distutils] Standardizing distribution of "plugins" for extensible apps

Bob Ippolito bob at redivi.com
Wed Dec 8 15:37:28 CET 2004


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



More information about the Distutils-SIG mailing list