[freenet-dev] workflow concept: automatic trusted group of committers (untested)

[Arne Babenhauserheide]

Am Montag 27 April 2009 17:11:54 schrieb Arne Babenhauserheide:
> Am Dienstag 14 April 2009 12:22:12 schrieb Arne Babenhauserheide:
> > A workflow where the repository gets updated only from repositories
> > whose heads got signed by at least a certain percentage of trusted
> > committers.
>
> Could someone comment on this?

I just uploaded the concept to my website to have it in one clear place: 

http://draketo.de/light/english/mercurial/workflow-concept-automatic-trusted-group-committers

Best wishes, 
Arne

--- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- 
   - singing a part of the history of free software -
  http://infinite-hands.draketo.de
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: 

[freenet-dev] workflow concept: automatic trusted group of committers (untested)

[Arne Babenhauserheide]

Am Dienstag 14 April 2009 12:22:12 schrieb Arne Babenhauserheide:
> A workflow where the repository gets updated only from repositories
> whose heads got signed by at least a certain percentage of trusted
> committers.

Could someone comment on this? 

It's quite security related, so I really need feedback on it... 

The reason for the workflow is to allow trusted groups to publish anonymous 
repositories. 

It should even work, if the group gets partly compromised, and it should allow 
regrouping as long as enough trusted people remain long enough to do one more 
update. 

Do you see any glaring flaws in the scheme? 
And does it sound useful to you? 

Best wishes, 
Arne

--- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- 
   - singing a part of the history of free software -
  http://infinite-hands.draketo.de

Re: [freenet-dev] workflow concept: automatic trusted group of committers (untested)

[Arne Babenhauserheide]

Am Montag 27 April 2009 17:11:54 schrieb Arne Babenhauserheide:
 Am Dienstag 14 April 2009 12:22:12 schrieb Arne Babenhauserheide:
  A workflow where the repository gets updated only from repositories
  whose heads got signed by at least a certain percentage of trusted
  committers.

 Could someone comment on this?

I just uploaded the concept to my website to have it in one clear place: 

http://draketo.de/light/english/mercurial/workflow-concept-automatic-trusted-group-committers

Best wishes, 
Arne

--- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- 
   - singing a part of the history of free software -
  http://infinite-hands.draketo.de


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

[freenet-dev] workflow concept: automatic trusted group of committers (untested)

[Arne Babenhauserheide]

Am Freitag 10 April 2009 18:30:29 schrieb Matthew Toseland:
> > 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?

Because then you don't have to ever trust one single developer (who might just 
have been caught by evil corp?) and at the same time you don't have to 
doublecheck every change yourself. 

You get a trusted group of committers with some room for people dropping out. 

> 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.

The scheme below should offer a way to do that. 

> > Are there any weeknesses in this scheme (except the possibility that
> > the majority of maintainers overlooks some bad code)?
>
> Dunno...

I reworked the scheme while I was in train this weekend (for mercurial). 

Goal: A workflow where the repository gets updated only from repositories 
whose heads got signed by at least a certain percentage of trusted committers. 


Requirements: Mercurial, two hooks for checking and three special files in the 
repo. 

The hooks do all the work - apart from them, the repo is just a normal 
Mercurial repository. After cloning it, you only need to setup the hooks to 
activate the workflow. 

Hooks: prechangegroup and pretxnchangegroup 

Files: .hgtrustedkeys , .hgbackuprepos , .hgtrustminimum


concept: 
- prechangegroup: Copy the local versions of the files for access in the 
pretxnchangegroup hook (might be unnecessary by letting the pretxnchangegroup 
hook use the rollback-info). 

- pretxnchangegroup: 
* per head: check if the tipmost non-signature changeset has been GnuPG 
signed by enough trusted keys. 
* If not all heads have enough signatures, rollback, discard the 
current 
default repo and replace it with the backup repo which has the most changesets 
we lack. Continue discarding bad repos until you find one with enough 
signatures. 

.hgtrustedkeys contains a list of public GnuPG keys. 

.hgbackuprepos contains a list of (pull) links to backup repositories. 

.hgtrustminimum contains the percentage of keys from which a signature is 
needed for a head to be accepted. 


With this workflow you can even do automatic update from the repository. It 
should be ideal for release repositories of distributed projects. 

Please tell me what you think about it! 

Best wishes, 
Arne
-- 
-- Ein W?rfel System: http://1w6.org - einfach saubere (Rollenspiel-) Regeln.
-- Infinite Hands: http://infinite-hands.draketo.de - singing a part of the 
history of free software.
-- My stuff: http://draketo.de - stories, songs, poems, programs and stuff :)

-- PGP/GnuPG: http://draketo.de/inhalt/ich/pubkey.txt
-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: 

[freenet-dev] workflow concept: automatic trusted group of committers (untested)

[Arne Babenhauserheide]

Am Freitag 10 April 2009 18:30:29 schrieb Matthew Toseland:
  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?

Because then you don't have to ever trust one single developer (who might just 
have been caught by evil corp™) and at the same time you don't have to 
doublecheck every change yourself. 

You get a trusted group of committers with some room for people dropping out. 

 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.

The scheme below should offer a way to do that. 

  Are there any weeknesses in this scheme (except the possibility that
  the majority of maintainers overlooks some bad code)?

 Dunno...

I reworked the scheme while I was in train this weekend (for mercurial). 

Goal: A workflow where the repository gets updated only from repositories 
whose heads got signed by at least a certain percentage of trusted committers. 


Requirements: Mercurial, two hooks for checking and three special files in the 
repo. 

The hooks do all the work - apart from them, the repo is just a normal 
Mercurial repository. After cloning it, you only need to setup the hooks to 
activate the workflow. 

Hooks: prechangegroup and pretxnchangegroup 

Files: .hgtrustedkeys , .hgbackuprepos , .hgtrustminimum


concept: 
- prechangegroup: Copy the local versions of the files for access in the 
pretxnchangegroup hook (might be unnecessary by letting the pretxnchangegroup 
hook use the rollback-info). 

- pretxnchangegroup: 
* per head: check if the tipmost non-signature changeset has been GnuPG 
signed by enough trusted keys. 
* If not all heads have enough signatures, rollback, discard the 
current 
default repo and replace it with the backup repo which has the most changesets 
we lack. Continue discarding bad repos until you find one with enough 
signatures. 

.hgtrustedkeys contains a list of public GnuPG keys. 

.hgbackuprepos contains a list of (pull) links to backup repositories. 

.hgtrustminimum contains the percentage of keys from which a signature is 
needed for a head to be accepted. 


With this workflow you can even do automatic update from the repository. It 
should be ideal for release repositories of distributed projects. 

Please tell me what you think about it! 

Best wishes, 
Arne
-- 
-- Ein Würfel System: http://1w6.org - einfach saubere (Rollenspiel-) Regeln.
-- Infinite Hands: http://infinite-hands.draketo.de - singing a part of the 
history of free software.
-- My stuff: http://draketo.de - stories, songs, poems, programs and stuff :)

-- PGP/GnuPG: http://draketo.de/inhalt/ich/pubkey.txt


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