How to make it more secure
You should look into YURLs.
The idea is to form a network of trust via introductions. Lets say the Rox site has a link to the GTK site. But the Rox site includes a hash of the GTK site's public key in the link. That way, if the GTK site is hacked or re-directed, the (browser) client will refuse to load it. Under the current scheme, you will only detect a problem if you had been to the GTK site before.
Given all the attempts at back-dooring the Linux kernel, etc, it's not too paranoid to be thinking two steps ahead.
In regards to 0install: I like it, but it needs managment tools. Each user should be able to "freeze" the application versions they like, so some other user doesn't "upgrade" them to a version they are unfamiliar with. At my university we had an application called SWSELECT that would allow you to set which version of each application you wanted to run. It just exported ENV vars like this:
Applications not listed would get the 'recommended version', which only changed once a term. But geeks could set their version forward or backwards to their heart's content. (based on what the university continued to support, of course).
Config file as File System
Turning configuration files into a whole filesystem could be an end in itself. Consider:
- Hans Reiser wants to make the filesystem intelligent so the an XML document could look like a directy of files. He will put the XML-to-directory-and-back translation into the filesystem. No code for you to write. (Poor Hans, doing our work. ;)
- Logging and archiving configurations would be a job for tar (or CVS). No new code to write. (ok, maybe a cron job and a nice 'restore configureation' GUI that calls untar.)
- Access control (ACLs) already exist, and will eventually become standard (just like journaling file systems have). Neither the application nor the C4G program will need any special permissions-checking code -- the filesystem will do it. GUIs may be needed to help the user delegate tasks, but the hardend sysadmin will just use chmod or chacl.
- Task automation (such as "delete the /tmp share from samba") don't need parse code anymore. These tasks can now be done with simple shell scripts.
- Remote administration would be a simple network mount. No new protocols, no new code. Accessing and changing data when the computer is down is alreay supported by file systems like coda and intermezzo. Until those become more robust and standardized, a file-sync program like unison can be used. (The advantage over normal config files: fine-grained sync reduces the conflicts).