1. What? |
1. What?Distributed Software Development is a process where many people, possibly from different geographical locations, work on a common software project. Especially "Free Software" and "Open Source" projects are often developed in such a distributed process. Sites like sourceforge.net provide a convenient platform for such distributed development, with the most important aspects of such a platform being
All of these can also be provided by freenet: for communications there are various well-established means like NIM, frost and fmb. Pseudonymous authentication works via SSKs. The tricky part that remains is the version-controlled software repository. Probably the most widely used repository software is "CVS". It has almost all of the important features one needs for developing software. Clients exist for most operating systems. And it doesn't lend well for porting to freenet because it relies on a centralized repository. The same is also true for some of CVS's alleged successors like "subversion". A rather new repository software is Tom Lord's "Arch". The good thing about Arch is that it's distributed by design, i. e. it's relatively easy to use together with freenet. 2. How?Basically, I have written a patch for Arch that enables it to access archives located at freenet:... type URLs, and to mirror an existing (local) archive into freenet. I'm also suggesting a naming convention for in-freenet-archives to be used instead of email addresses. 2.1. NamespacesThe important part of defining a namespace for Freenet-based Arch-controlled projects is that everyone must be able to create a globally unique ID for themselves and their projects while making it reasonably difficult for anyone to impersonate them. In the non-anonymous internet, email addresses provide a namespace that fulfills these requirements: to generate a valid email address you must have control over the mailserver for the domain. The domain name system guarantees uniqueness of the domain part, the mailserver operator guarantees uniqueness of the local part. Of course anyone can claim to be "linus@transmeta.com" or "rms@fsf.org", but they will quickly be identified as impersonators when someone tries (and fails) to reach them at these addresses. In Freenet, the only means to satisfy the requirements is probably the SSK namespace. Global uniqueness isn't actually guaranteed, but due to the sheer size of the SSK namespace it is extremely unlikely that two people by chance generate the same SSK for themselves. Impersonation is also extremely difficult because SSKs are cryptographically secured (remember, "SSK" means "Secure Subspace Key"). 2.1.1 User IDsIn order to accomodate SSKs as part of the unique user ID a small extension could be made to the original specification of the unique ID syntax in Arch:
An alternative is to generate SSKs over and over again, until the public part doesn't contain any tilde character. This is (for now) the preferred and implemented method. The suggested pattern to form a unique ID for Freenet-based Arch projects is, then:
Rationale: there is no top-level domain "freenet", and hopefully there will never be one. Therefore,
As a general rule, the owner of such a user ID should maintain a freesite at "freenet:SSK@SSK/nickname//". 2.1.2 Archive NamesQuoting from the (old) Arch documentation, section 9.2: An archive name consists of an email address [...], followed by "--", followed by an additional string of numbers, letters and dashes [that must not contain two consecutive dashes]. (The stuff in brackets was inserted by me, and has been suggested to the Arch developers because it fixes an error in the current specification.) By substituting "email address" with the "unique ID" as defined in the previous section we can easily extend the existing namespace for archives to accomodate in-Freenet-archives. The nice thing about that definition is that the "unique ID" in the archive name can automatically be mapped to a freenet key (as described above) containing the actual archive. (A freesite that's published under the same key conveniently does not interfere with the archive at the same location. When using fcpputsite, both must be published simultaneously, though.) 2.2 Preserving AnonymityThis is one of the tricky parts. I have already talked about namespaces and how to choose an arch user ID and archive name that won't give away your email address. It is your job to follow these suggestions! Another issue concerning anonymity is file paths. Section 5.1 of this document suggests a setup that's as anonymous as possible. Again, it is your job to follow these suggestions! Both of the above points can relatively easy be followed by invoking the command "larch new-freenet-project" in an appropriate directory location. See the help message of that command for more information. Finally, there is the problem of user and group names in tar archives. Arch stores patch sets as a simple tar archive containing plain diffs and some meta information. Tar files created by you contain your user and group names and IDs! Therefore, publish-freenet-mirror will use the included "anon-tar" command to anonymize the tar files before publishing them. 2.3 The Arch PatchThe Arch Patch implementing the described changes is available at
You can either download the source tarball, or access the arch archive at the same URL using arch itself by entering
For bootstrapping (and for simplicity :-/) the archive site is mirrored at
and
The patch requires fcptools to be installed. The current version is pretty alpha, use carefully! In particular, I'd recommend to backup your local archive before trying publish-freenet-mirror. 2.4 Known Problems
2.4 Getting StartedFirst, you should get familiar with arch, e. g. by reading this tutorial. Once you understand how to operate arch, understanding how to operate arch over freenet becomes very simple:
3. Why?So why does anyone need to develop software in freenet when there are already nice and convenient platforms like sourceforge available? Several reasons come to mind:
4. Improvements & Suggestions
5. Good PracticeThis section contains a few hints on how to set up a project for development via freenet. 5.1 AnonymityIf you choose to develop a software project via Freenet it is not unlikely that you do so because Freenet offers anonymity. Anonymous development is quite uncommon in Open Source and Free Software Projects, though, and therefore revision control software is usually trying pretty hard to make sure you receive credit for your contributions. So you should choose to set up a development environment that makes sure Arch does not include any hint on your identity into the project repository. First, you should set up an encrypted filesystem, e. g. using loopback encryption on a linux machine. Make sure it is mounted under some unconspicuous name like "/encrypted". (Using e. g. "/home/torvalds/cryptofs" would probably be a bad idea if your name was Linus Torvalds.) Second, create an unconspicuous "development home" directory on the encrypted filesystem. Like e. g. "/encrypted/dev/CoolProject". Third, change your $HOME environment variable to point to that directory before setting up your arch environment and the rest of the project. This is a little tricky, because if you do this manually in your shell the commands may end up in your shell's history file! Therefore, create a small helper shell script (with an unconspicuous name, of course, like "/encrypted/script1") that contains something like this: #!/bin/sh HOME=/encrypted/dev/CoolProject export HOME cd $HOME $SHELL -i
Only after executing that script should you initialize your arch environment
and work on the project. Arch saves configuration information in
"$HOME/.arch-params",
which will automatically end up in the encrypted filesystem. Of course you
should create your {archive} and {repository} on the encrypted volume, too.
It might be clever to use a different {archive} for each project, so you
can publish them independently. And don't use your email address as your
Arch user ID! 5.2 Project ManagementFor rapid publication of new patches you should publish your archive as an edition based freesite. Immediately after creating a patch you should insert a new edition of the archive freesite. Using the naming convention described above (see section 2.1.2) you can publish a link to the new version immediately after uploading, e. g. via frost. At the same time you should maintain a DBR site that is regularly updated to point at the latest edition. This way, your co-developers can quickly get the latest version of your archive, while others can use the (never changing) DBR link to retrieve a current but not necessarily absolutely latest version. The default page of your freesite should contain:
|