Slashdot Mirror

Indeed, you've got to start somewhere, and for SSL there is this whole PKI thingy, with a few reasonably trustworthy CAs and with a few reasonably trustworthy ways of getting CA root certificates (ie. provided by popular browsers or by OS).

This is about choosing a point on Zooko's Triangle [warning: self-signed certificate]. HTTPS PKI as deployed chooses to rely on a small set of trusted third party identification services. This has two limitations: in security parlance "trusted" means "able to subvert YOUR security if it doesn't perform as advertised", and it requires real-world-linkable identification which is a nonstarter in anonymous systems.

That said, trust chaining still works in anonymous spaces. If you trust Alice (say alice4b8ajlnt9pq.onion) to supply you with secure links, and Alice gives you a link to Bob (say bobqiprlcn38afdc.onion), if that link resolves successfully you can be sure you are talking to the same Bob that Alice intended.

If all you have is a hash, how do you verify that the hash (and therefore corresponding data) is original and not for example changed by a man-in-the-middle-attack?

How do you define "original"? If you define it as "signed by a key linked to a known real-world identity" you have excluded anonymous protocols by definition. If you define it as "received through a different, reasonably trustworthy channel", it's on the same footing as real-world PKI: "reasonably trustworthy". In either case, the salient point is that in both examples I gave, the address is the hash, therefore you must have received the hash before beginning to retrieve the data.

You hit the nail on the head. Distributed version control often comes with superior merging, making the process less painful and encouraging it to occur frequently. Monotone employs a 3-way merge, Codeville has an innovative merging algorithm, and some may even support 5-way merging ("left's immediate ancestor, left, merged, right, right's immediate ancestor") in the future.

In my experience, nearly all merges occur automatically and cleanly. Only if two developers modified code in conflicting areas of the source code do you have to merge manually--and even then, only one person has to do it. It is much better to have merging operate automatically and transparently when possible, than to have to have two people manually coordinate each and every one of their changes beforehand.

"The better SCM initiative was established to encourage improved OSS/FS SCM systems, by discussing and comparing them. Among other things, see their comparison file. Zooko has written a short review of OSS/FS SCM tools. Shlomi Fish's OnLamp.com article compares various CM systems as does his Evolution of a Revision Control User. The arch folks have developed a comparison of arch with Subversion and CVS (obviously, they like arch). Another pro-arch discussion is Why the Future is Distributed. A pro-subversion discussion is available at Dispelling Subversion FUD. Slashdot had a discussion when Subversion 1.0 was announced. Kernel traffic posted a summary of a technical discussion about BitKeeper. Brad Appleton has collected lots of interesting SCM links. jemfinch has some interesting essays about SCMs (he uses the term VCS), including why he thinks the approach to branches used by Darcs, Arch, and Bazaar-ng is a poor one. A brief overview of SCM systems that can run on Linux is available."

There are lots of OSS/FS software configuration management (SCM) tools. CVS, Subversion (SVN), and GNU arch get lots of press, but there are many others such as Aegis, CVSNT, Darcs, FastCST, OpenCM, Vesta, Codeville, Bazaar and Bazaar-NG.

You might also take a peek at my paper Software Configuration Management (SCM) Security.

The reason that crypto can never really be made 100% convenient is Zooko's triangle: you want the name by which you refer to your correspondant to be memorable, globally unique, and free from centralized control, but you can't have all three (see also Clay Shirky's restatement of this idea). So if you want to use email addresses, someone has to be the centralized authority from which is ultimately derived your right to state that you are the legitimate recipient of a certain email.

If we had DNSSEC - if domain authorities routinely certified DNSSEC public keys with the same authority by which they allow name server records to change - then this would mean the central authority was at least doing their job properly and we could use it to build an email infrastructure. But then people wouldn't pay Verisign for certificates, so that would never do.

Like CVS, you can get productive within minutes; the same cannot be said for Arch or even Subversion. Let's see:

john@somewhere$ cd ~/myproject
john@somewhere$ darcs init

You now have a Darcs repository! Let's do something with it:

john@somewhere$ darcs add -r *
john@somewhere$ darcs record -am "Initial import."
Finished recording patch 'Initial import.'

Now your repository contains all your files. Let's look at the changelog:

john@somewhere$ darcs changes
Thu Nov 25 06:26:19 CET 2004 johndoe@example.com
* Initial import.

Now, where's the server? You need a server to share your repository, right? Nearly -- every repository is a potential server, as long as it's accessible either through the file system, through SSH/SFTP, HTTP or email. Let's go to another machine and check out the repository we just made:

jane@elsewhere$ darcs get john@somewhere:~/myproject
Copying patches...
.
Finished getting.

We now have a repository on Jane's box. Let's make a modification:

jane@elsewhere$ echo "#include <foo.h>" >>foo.c
jane@elsewhere$ darcs whatsnew --summary
M ./foo.c +1
jane@elsewhere$ darcs whatsnew
{
hunk ./foo.c 2
+#include <foo.h>
}

This last output, by the way, is Darcs' patch format. A "hunk" is a line-based diff. Other types of changes that may be contained in a changeset include renames, moves and binary changes. (Yes, you can also get a GNU-patch-compatible output similar to "cvs diff".)

Now let's commit and push the changes back to John's repository:

jane@elsewhere$ darcs record -am "Added a missing include."
jane@elsewhere$ darcs push -a
[...]
Finished applying...

Now we can go back to John's machine and look:

john@somewhere$ darcs changes
Thu Nov 25 06:26:10 CET 2004 janedoe@example.com
* Added missing include.

Thu Nov 25 06:26:19 CET 2004 johndoe@example.com
* Initial import.

(Note how Darcs generates a GNU-style changelog for you automatically.)

Where are the revision numbers, you ask? Well, they don't exist, because they're not needed. Darcs is changeset-oriented, not file-oriented. You can refer to a changeset by name, date, or a special hash identity.

Darcs changesets aren't just GNU patches; they have context, which means, for example, that someone can check out a repository, move a file "foo.c" into the directory "bar" and commit; meanwhile, another person, working on an older copy of the same repository, edits foo.c (which is still in its old location) and commits that. Darcs know that this edit should apply to foo.c in the new location -- and unlike CVS, you don't need to do anything similar to "cvs update" if you're committing files that have been changed on the server. In other words, people can freely commit changes, and the only kind of visible "conflict" will occur when you actually edit the exact same line.

Unlike CVS and Subversion, but like Arch and Monotone, Darcs is a distributed version control system. Repositories are islands which are constantly out of sync with each other, and Darcs' patch commutation system takes care of integration the changes that flow between them.

This system has several extremely useful effects:

• Offline mode. You can commit changes even if you're on the road with no access to the server. That's because your own working directory is a repository in its own righ

How about Darcs?

I was just recently looking to move away from CVS for my personal projects. I'm not always home, and I wanted to have copies of my repositories on at least my laptop and desktop.

At first, I was leaning towards trying out GNU Arch. But I really wanted something that had a working win32 client. So I took a look at Darcs.

I'm very happy with it so far. It is extremely easy to set up and use (but I haven't seen any gui frontends if that's the kind of thing you want). It is also very easy to keep multiple repositries in sync.

I've read that it can be slow for large projects. I don't remember reading the definition of large, but none of my repositories qualify :).

You might also want to check out this comparison or this comparison of revision control systems.

It's a consequence of Zooko's Triangle. See also Clay Shirky's
Domain Names: Memorable, Global, Non-political? In summary, there are three properties you want from a naming scheme:

* memorable names
* globally unique names
* names free from centralized control

Of these properties, you can have any two.

Now, CVS is less than perfect, but considering the entirety of FreeBSD is developed using it [...]

A lot of FreeBSD development occurs using Perforce. See for example this and the mailing lists here.

Here's a good comparision of source control systems.

It's worth a look, if only for the ideas.

Mojo Nation was conceived by Jim McCoy and Doug Barnes in the 90's. At the end of the 90's they hired hackers and lawyers and started implementing.

Their company, Evil Geniuses For A Better Tomorrow, Inc., opened the source code for the basic Mojo Nation node (called a "Mojo Nation Broker") under the LGPL.

During the long economic winter of 2001, Evil Geniuses ran short of money and laid off the hackers (the lawyers had already served their purpose and were gone).

One of the hackers, me, Zooko, and a bunch of open source hackers from around the world who had never been Evil Geniuses employees, forked the LGPL code base and produced Mnet.

Now there is a new commercial company, HiveCache. HiveCache has been founded by Jim McCoy.

BTW, if you try to use Mnet, be prepared for it not to work. Actually the CVS version works a lot better than the old packaged versions. We would really appreciate some people compiling and testing the CVS version (it is very easy to do, at least on Unix).

It would be really good if someone would compile the win32 build. We do have one hacker who builds on win32, but we need more.

Hi folks. The License Quick Ref is definitely a work in progress. I am no lawyer and there are a lot of question marks and probably a lot of inaccuracies or other bugs.

Please e-mail <zooko@zooko.com> with suggestions for improvement. Thanks!

If you send me flames, I may elect to post them to my web log. :-)

http://zooko.com/.

Regards,

Zooko