CPAN for python?

[Randall Hopper]

Christian Tismer:
 |Randall Hopper wrote:
 |> Andrew Kuchling:
 |>  |So, what would people want on top of distutils?  A Debian-style "do
 |>  |apt-get, upgrade" to update currently installed packages?  A
 |>  |CPAN-style "fetch and install this module for me, please"?  Simple
 |>  |version checking?
 |> 
 |> I guess I've been spoiled by the FreeBSD ports system.  Fetch the small
 |> port for a package and just kick off "make install".  Under the hood, it
 |> fetches source dists from ftp/www sites, and patches, configures, builds,
 |> and installs the package _and_ all its dependent packages, all
 |> automagically.  Simple (particularly good for the newbies).
 |
 |Sounds great.
 |Do you have an idea how they handle the security
 |part of the game?
 |If this kind of thing, with multiple ftp servers involved
 |and scripts in several packages being auto-called, gets
 |tampered by a moderate level hacker, (s)he could do quite
 |everything nasty.

I'm not sure I fully appreciate your question, but here goes.

On UNIX, packages are typically installed in common directories only
writable by root.  That protects the integrity of Python, distutils, and
friends from tampering unless your root account is compromised.

The real vulnerability is in the downloaded software (I think that's what
you were referring to).  Did it come from a trusted source, or has it been
verified by a trusted authority?

Two things come to mind with regards to this verification.  All ports are
fetched from ftp.freebsd.org (or an official FreeBSD CD, etc.).  So you
know that someone working for the project has signed off and committed
their name to public CVS as checking the port in as a working, useful port.

That leaves the actual source distribution fetched and built by the port.
The port contains the full URLs to the source dist files, so you can have
confidence those haven't been tampered with.  The port also contains an md5
checksum for the package the port was built against.  If that doesn't
match, the port build is failed.  This guards more against the port
maintainer changing the package after the port was cooked, rather than
being a security measure.  But it could help.  A full digital signature for
the package stored in the port would be better for security.

Key point:  All the "get this package from here", "build this dependent
package", etc. except the user's initial "make install" command comes from
the ports, and these come from the trusted distribution authority.

It's certainly not fullproof but it's pretty good.  If someone hacks DNS
and routes your FTPs/HTTPs to an alternate host, you could be hosed.  If
someone compromises the package author's download machine or ISP web server
where the package lives, you could be hosed.  However all this is also true
for the case where Joe Developer mails out a URL to a Python module so you
can fetch and build it by hand.

I think the key is having a central distribution point for
Python module distributions (or those "getit.py" scripts I was talking
about -- whichever).

For module dists/getit.py scripts not fetched from this central repository,
users of course have to be just as careful with what they fetch and give
control of their machine to as they do any other package.  Did it come from
starship?  python.org?  Some dark site deep in Libya. ;-)

 |And it would be cool to host this service on the new
 |Starship site which is being built at the moment.
 |The machine is very powerful.

Agreed.  Also a good distribution authority since folks could trust module
dists pulled from the site.  Ideally they'd be trial-installed once before
being put up for grabs, or maybe there's a testing record attached to the
download page for each (e.g. installed by tismer at tismer.com on 6/8; seems ok).

-- 
Randall Hopper
aa8vb at yahoo.com