Let's say that I'm regarded as smart enough to provide suggestions for this "something". And that I regard a number of people on daemonforums.org as considerably smarter then I am on such matters. For me, all of this is the best way of doing it that I can personally think of. If anyone is actually still interested after reading the basic idea below, I would really appreciate constructive comments on this thing, negative or positive alike -- because I'd rather be found wrong here then suggest it and see it put into use for this "something". And if anyone is wondering, no I do not really like creating threads like this.

Ok, this is the basic idea.

Users can install add in 'modules', hopefully downloaded from a trusted source.

Users can create 'modules' and have reputation based sharing, e.g. do good, project will host the module, do bad, your requests are > /dev/null.

The idea I was thinking about, for the process. The user would download the module and try to install it (software would of course take care of this). The module is an archive containing:

So in essence the installation process amounts to extracting the files archive into the right place, for them to be 'imported' locally.

We want to ensure that

The module has not been modified since it was created and downloaded

The module is from a reliable source |or| warn user

Force expiration of official 'trust' for modules created by an author

The concept:

The checksums file contains md5/sha256 checksums of the files archive, verifying those should reasonably prove that the archive is nether corrupt or tainted. To ensure that the checksums file has not been changed itself, such as by a malicious user wishing to drop a payload in a replacement files archive -- the checksums file is digitally signed with the private key of the modules author.

To verify the signature of the checksum file, we need the public key. So we download a digitally signed database file from a key server over HTTPS, which is *trusted* to have a valid database file. Once the database file is downloaded, we verify the database files signature with a public key specific to that key server.

The user does not need to trust the modules author or the files on the host, but they should be fairly sure that if the key server trusts the author, they won't get something malicious from the host site. This database file contains the necessary data to verify the digital signature on the checksum file -- comparing the fingerprint and author with listed in the info file, then on a match attempting to verify the checksum file with the corresponding public key in the database. In the advent of failure to verify, the user is essentially put in the "Proceed at your own risk, we warned you, so don't shout at us if you get burned!" boat. If the author of a module repeatedly submits crap, the public key is revoked and their keys removed from the trusted systems, then there modules are deleted from the host.

Does anyone see any big flaws in this, that I don't? Because the only biggest flaws I see is relying on fetching the database from the *right* host and getting the keys in the db cleanly. I'm not really a cryptography kind of guy but this is what idea I'm planning on recommending for this "something".

For the source of the modules:

A user wishing to share their custom modules with other users of the software service goes to a specified website. Creates an account with the necessary information and supplies a "salt" value for key generation. Combine parts of the account data and their salt value, apply a small series of modifications, that in the site designers theory should create a unique passphrase via one way hash function to use for the key pair, that can not be guessed solely on the input to the user account, and never (within reason) generate the same output from the same input or something like that I'm told.

Generate a DSA public/private key for the user account, saving the public key and giving the user their private key via HTTPS. This key pair might be created via third party software or through a suitable library.

The "key server" housing the database of author public keys, user names, and fingerprint, that this host trusts (in regard to the modules; not the actual user accounts of course!). Would have the keys entered into the database via some secure way of feeding them to the sever from the web host. <---To me this is probably the weakest link. Another machine would then provide access to the server with the database via proxy. The outside accessible machine network mounts a read only copy of the database from the secure database server.

The theory being, if the server (e.g. proxy) that people will fetche a copy of the database from is compromised, there is no way for an attacker to corrupt the actual "master" copy of the database through the 'proxy server'. Unless they penetrate the network and gain a trusted shell on the actual box with the database. And to top it off, the database should be stored under a versioning system with the repository residing on yet another machine. The only machines directly exposed to account holders should be the proxy server for downloading the database and webservers providing account creation and the modules for download. The rest (e.g. real database server, repository for database, and probably authoritve storage for the modules) would be as segregated from the web servers as strongly they can make them.

Does this sound like a feasible implementation or is this whole phase of it just a brain fart?

The creator of a module registers his module on a web site, submitting a hash of his module together with a description. From the web site an administrator with write access reviews his module and submits it into a central database. The module creator cannot write to the database himself.

This database is mirrored read-only to users who download a copy of the database and compare it's signature with a key shipped with the system.

You might recognize this: It's the FreeBSD ports system when used with portsnap!

It misses the digital signature of the module by its owner. But to me this is the critical point. The web site should never have access to the private signature key. Therefore it must be created by the user. But how to we know that the user is trustworthy? He must be identified and his public key must be 'certified' in some way (e.g. by including in the database or by assigning it to a certificate).

This is how 'code signing' works, like it can be found in Windows installers or some Java applications. But it requires 'processes' (application, revocation). While many things can be automated someone has to review the application. Large organizations (like the FreeBSD community) operating for free will probably not be able to handle these processes. Despite that, educating the module creators how to create their keys and keeping them secure would be a difficult task.

I think if the community of module creators is small and well 'educated' your proposed system will probably work. But if your community grows large it will require a lot of work.

I think you have a good point that the web server should never have access to the users private key. The only thing that worries me is module creators would have to learn to create the key pair, submit the public key, and defend the private key. I suppose though that SourceForge.net manages the task well enough with SSH setups.