On Tuesday 07 April 2009 09:24:10 Arne Babenhauserheide wrote: > Am Samstag 04 April 2009 22:50:11 schrieb Matthew Toseland: > > Agreed, however we need to be careful as we can be sued for any > code which is copyrighted by somebody else; if we can provide the > would-be litigant with the identity of the committer, we don't have > this problem. > > Sure. > > That's why someone needs to maintain a frenet-only pseudonymous > version of the repository where all pseudonymous contributions can > be gathered. :)
:) > > That pseudonymous version can then contain additional features, so > users have a rason for switching to it. > > We just need to find a way to make sure that this pseudonymous > repository doesn't get compromised. Well, that disqualifies me - I'm traceable. > > > I think it would be nice to do this as repository which can be updated > only if at least 60% of a specific group of people agree. Why is that beneficial relative to a fully distributed model of people pulling if they like a patch? > > Ideally with also the option of adding new people to the group if > enough people agree? > > Example: Assume that we have 5 trusted maintainers. If one of them > now wants to push some changes to the reference repository, at > least two others have to agree to get the new revision into freenet. > > If another maintainer joins the group, they need 4 people for pushing > code online, and if two leave the group, two people suffice. (joining > and leaving would need to be done as greoup decision - needs 3 of 5 > for example). Such a mechanism will be necessary for trusted freesites in general - the reason we don't have an official freesite is what happens when the private key is compromised? The most basic scheme is to have a single revocation key, which if found indicates the key has been compromised, which can be inserted by trusted people. But it would be much better if each trusted person could have his own revocation key, and they could vote on adding new trusted people / kicking them out, and on recovery from a compromise of the main key. > > It would be possible to implement this check decentrally: Each head > must be signed by a majority of the keys which are saved in freenet > to be accepted locally, else the foreign repository will be marked as > compromised. > > If the list of trusted keys is part of the repository, it will be possible to > update them. > > Ideally there should also be a mechanism for backup locations and > changing them. For example this could be done by having a list of > them in the repository. When the main repository gets > compromised, freenet should check the backups for updates. > > Adding in a few safety checks (always need backup locations and a > minimum number of maintainers), this looks to me like it should > work. > > Are there any weeknesses in this scheme (except the possibility that > the majority of maintainers overlooks some bad code)? Dunno... > > Best wishes, > Arne
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ Devl mailing list Devl@freenetproject.org http://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl
