[Pythonmac-SIG] Package Manager idea, adding a URL scheme

Bob Ippolito bob at redivi.com
Thu Oct 2 18:37:05 EDT 2003

On Thursday, Oct 2, 2003, at 17:48 America/New_York, Jack Jansen wrote:

> On 1-okt-03, at 21:11, Ronald Oussoren wrote:
>> Another idea: Add a function of comparing versions to pimp.
> The intention was that there was going to be a default version check 
> that worked
> exactly this way. This should be done for the next version. The default
> version check should probably first use a verbatim string equality 
> check, if that
> fails get '[0-9.]*' from both versions and compare those for less and 
> greater,
> and if those are identical but the rest of the version strings differ 
> give up.

I suppose I'll go ahead and start working on the next version of 
pimp/packman, since I'm maintaining the larger database and you don't 
seem to have a lot of time on your hands.

>> BTW. I just noted that PackMan (the GUI) doesn't have an 'uninstall' 
>> option. That makes it harder to throw away packages that are not 
>> really needed.
> distutils should support this, then it would be easy. There's hooks
> in pimp to record what files have been installed, but as this 
> information
> is incomplete I didn't follow up on it. For binary installations life
> is easier, as we *do* know what has been installed, but there still 
> another
> problem: installs can overwrite existing files, so we should stash 
> these
> away somewhere. For this we could probably look for good ideas in other
> installers.

Perhaps it should prompt the user?  I think that's what most installers 
do (unless they're preserving stuff so you can roll back, which may or 
may not be a desired feature).  Generally speaking, a given package 
will only be overwriting files from a previous version of itself, 
unless it's an upgrade to something in the standard library or 
elsewhere on your computer which will require administrator access.

> And Just said:
>> - I really dislike PackMan executing code from the .plist
> I can't think of any other way to make things truly extensible.

Well we're only talking about detecting a previous version of a 
particular module or package.  I'm sure we could develop a reduced 
syntax that only allowed read only access to files that could parse 
python code down to abstract syntax trees and extract module level 
variables with the capability to regex them a bit.  That should cover 
just about any conceivable case without actually executing anything 
completely arbitrary.

> But we should definitely allow for some sort of public key scheme to
> be used. I've been toying with the idea of using the secure http of
> your browser, something like a "check integrity" button that would
> take the MD5 sum of the database, get an entry IntegrityCheck from
> the database (of the form 
> "https://www.python.org/pimp/integrity/%s.html")
> fill in the md5sum and send your browser there. Probably the user
> should get a dialog first (from pimp) explaining how to check the
> integrity (look at the padlock) and what it means (you're only trusting
> the fact that whoever maintains the website also created this pimp
> database).

I already purchased a GeoTrust (browsers trust this CA by default) SSL 
certificate for pythonmac.org with this purpose in mind.  I'm not big 
on the MD5 sums of databases thing, I think that it should be done with 
signatures, a la GPG.  That way the author could update the database, 
without python.org updating its, because the public key is the same.  
Say for example https://python.org/pimp/integrity.plist lists the 
public keys and/or SSL certificate information for each well known 
trusted third party database, upon going to that database it can verify 
the contents by way of the signature and/or SSL certificate.  One or 
the other (signatures or SSL) should be enough, both prevent man in the 
middle attacks, but both are susceptible to either the 
signature-owner's computer being compromised, or the SSL webserver 
being compromised, which is an unlikely event.  Using both wouldn't 
hurt though.


More information about the Pythonmac-SIG mailing list