Sure, we've all got our methods, but the point of this is to
provide something for people who don't know how to use such tools. So
that every new Drupal users can quickly and easily update their
modules and themes, without ever hitting FTP or the command line.

Also, we're working on secure ways to download the packages using
openSSL or gnupg or whatever will work cross platform and be secure.
Check out the link mentioned to learn more about the effort, would
love your input on how to accomplish this big usability
improvement.

This would be just great -- a relatively simple way to perform
updates. Funny, but I was just on the phone this AM with Alex Lindahl
of Acquia about my interest in handling this sort of thing on my own,
as a site owner (rather than paying for external support to do this,
as I'm doing now). Though it seems like it's not that complicated,
it's also a process that's subject to glitches -- meaning it's not
something you really want to do if you don't feel like you can
backtrack...

I don't want to suggest that the scope of this be extended
unnecessarily, but I would just like to point out a few key pieces
here:

1. If there's any way to hook this into a module/tool for backups,
that would be great.

2. One key piece, on the backup front, is ensuring the backups
actually work and can be used to restore a site. How does one do that?
For the non-geek, that's a pretty tall order -- testing out a backup
of a Drupal site to make sure the site can be restored.

"1. If there's any way to hook this into a module/tool for backups,
that would be great.'

There is the Backup and Migrate module, although it is likely to
stay in contrib, we could allow it to hook into this process and
provide a quick backup link there.

Restoring is another dicey topic. The only way to safely do this
in Drupal now, is to take the site offline, backup the code and DB.
Then a restore will be safe, otherwise, anyones' guess. There is no
separation of "user contributed content" and "the backend system"
which means, you cannot roll one back without affecting the other.

For this to work the way you describe it, wouldn't you have to set
your module and theme directories as writable by the web server
itself? Wouldn't that make Drupal more vulnerable to attack,
especially on a shared host?

Right now, I believe that only the settings file is writable by the
server - an attacker could overwrite or erase settings, but that's
about it. With the modules or themes writable by the server, it could
allow an attacker to inject PHP code into currently installed modules
and/or themes.

If done skillfully (or, more likely, when someone skillfully writes
a script for the kiddiez), the site owner and visitors would not see
any change to the site, but the malicious code would run on every page
load - for example, having the site send out a few spam messages, or
pulling the plain-text password from the login form.

Don't know if you heard about it, but VAserv was hacked hard this
weekend. I had a VPS that was among the casualties there, so maybe I'm
a little more sensitive to these issues right now, but I'd like
security to be (remain?) a priority in the D7 design process.

Please click through the 2nd round wireframes, or go visit this
issue at d.o. We're actually a little hyper paranoid about security.
People will have to provide their ssh/ftp creds when installing and we
won't store the password.

Hi Jacob - thanks for the pointer, I overlooked those links. So
it'll be a push from d.o via (s)ftp then? That's an interesting
approach - seems to negate my concerns quite well. Should be
interesting to see how the final product works.

1. The local Drupal site downloads the file from d.o
2. It confirms that the md5 sum of the file matches that published by
d.o (to reduce potential for dns poisoning - this happens
automatically via ajax, ideally)
3. Ask for ssh/ftp credentials every time, so someone with knowledge
of ftp/ssh has to do the action
4. The local Drupal site opens an FTP/SSH connection back to itself
and does the install. This allows all code files to remain "read
only" to the webserver and yet be replaced by the server acting as the
user specified in the FTP/SSH.

It's always been my understanding that if this was not implemented
via a system like Drush, it was not getting into core. This still
seems good to me, plus it's a big win for drupal hosting focused
companies, and still maintains a higher standard of security (as I
understand it).

That said, you should take a look at how Aegir displays these sorts
of details, it's a great inspiration to draw from.

Very good idea, and I second the linking or integration with Backup
and Migrate, evenif it is just recommending that or a similar module
and letting someone invoke it from page 2 in your wireframe. I think
this would otherwise be a hurdle for many. Thanks so much for taking
this one, it will make many people's lives easier.

My workflow is shorter than what you describe via SSH: copy link
from update status, 'wget $path, and 'tar zxvf' but doing this on the
back end for many modules at once would be a good thing.

What would make it even more interesting would be to expose
community features such as 'X bugs filed since release' or 'X bugs
related to release filed'. Or have some sort of a ranking for module
reliability.

Of course, the problem is that the community works differently on
different modules. For CCK, Views, Panels, the bug counts are
staggering but yet they are reliable, widely used and people just
report more bugs. But for smaller modules, I always wait a few days
and check the issue queue before updating.

Of course, Joomla has had a similar system for a while (at least
direct upload if not sync with repository) and it plays havoc with
permissions on shared hosting: you may end up with directories only a
root can delete.