On Tue, Nov 12, 2002 at 09:15:41PM -0600, Edgar Friendly wrote: > Ian Clarke <ian at freenetproject.org> writes: > > > For a while now, we have been working on the distribution servlet, which > > is basically designed to allow people to give copies of Freenet, together > > with seednodes, to their friends - effectively augmenting the current > > centralized pull model of software distribution with a decentralized push > > model. > > > Fair enough. I'm pretty happy that someone will come up with > something that works if/when it's necessary. But I really doubt it'll > be necessary. Um, the Distribution Servlet is absolutely necessary. The current model of everyone downloads from freenetproject.org and uses hawk's seeds is totally unsustainable, not just because it is centralized but also because it distorts the network. > > > There is at least one question that hasn't been answered yet : when you > > push a copy of Freenet to your neighbor - should it be the latest jar > > (perhaps distributed over Freenet using a DBR), or should it be the jar > > that you are using? > > > There's no way to enforce that it's the jar you're using, so we might > as well send the latest jar. Actually, it is technically possible to generate the JAR at run time, oskar coded this into dist servlet. We use the JAR if available though. > > > The advantage of distributing the latest jar is obvious, but the > > disadvantage is that it creates a danger that whoever has the private key > > with which these jars are inserted - could be compromized, allowing > > future Freenet jars to be corrupted. > > > This is starting to sound like a trusted 3rd party. It's not a bad > idea, but people should definitely be able to disable auto-updating. Of course. > > > IF we do the latter (or even just offer the latter as an option), we need > > a way to defend against a situation where the jar is compromized. One > > way would be to give a number of people "veto" rights over a jar. So lets > > say I or Oskar noticed that the current jar was corrupt in some way - we > > could veto it by inserting a message into our private veto-subspaces. > > This message could possibly contain a new subspace which nodes should use > > instead. If multiple veto subspaces are disagreeing with each-other, > > then the subspace given by the majority of those veto subspaces should be > > used. > > > The idea of veto subspaces corresponds closely to certificate > revokation; something that very few clients check. Of course there's > a performance penalty to checking all veto subspaces, which should be > considered. Hmmm. Without some sort of verification, we rely on the security of the insertion SSK, and if that is broken, all is lost. > > > Thoughts? > > > > Ian. > > My main thought about veto subspaces is that if there's multiple > contradicting vetos, the user should be presented with all the > information and allowed to make a choice however they want; a simple > majority algorithm seems like a bad idea. You might have a point. Though there is the possibility of unattended nodes, so we might have several possible verification modes. > > Thelema > -- > E-mail: thelema314 at swbell.net Raabu and Piisu > GPG 1024D/36352AAB fpr:756D F615 B4F3 BFFC 02C7 84B7 D8D7 6ECE 3635 2AAB >
-- Matthew Toseland toad at amphibian.dyndns.org amphibian at users.sourceforge.net Freenet/Coldstore open source hacker. Employed full time by Freenet Project Inc. from 11/9/02 to 11/11/02. http://freenetproject.org/ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: <https://emu.freenetproject.org/pipermail/devl/attachments/20021113/0338d9e2/attachment.pgp>
