search

voteflux / flux-docs

Documentation for Flux Parties and the Flux Movement. Covers party setup, social media policies, IBDD and philosophy, internal practices, governance procedures, and all the stuff in between. WIP.
4 stars 7 forks source link

Signing documents #6

Open pwhipp opened 6 years ago

pwhipp commented 6 years ago

Any document in this repo may be referenced using a specific commit as was done for the ACT constitution (but not the other constitutions btw).

In the source constitutions file we had: CONSTITUTION.ACT.md is accepted and ratified as the opening constitution of Flux ACT as defined in commit c37c68126e3c9d354d8bb66496d8efd6d9b35caa which is verified (and provided) at the following URL: https://github.com/voteflux/flux/blob/c37c68126e3c9d354d8bb66496d8efd6d9b35caa/CONSTITUTION.ACT.md (note the commit hash - the long string of randomish letters and numbers - matches the commit hash in the URL, indicating the document is correct and not tampered with).

As the constitutions file itself was not hashed, this text has been removed for the time being making ACT the same as the other constitutions.

I'm unsure of the legal requirements here but the entire constitution folder could be hashed and we could have another special (signed) document containing the hashes.

Signing a document means taking its hash and encrypting it with a key such that the document cannot be changed without invalidating the signature. The signature can easily be checked but cannot be 'forged'. We would be better signing the constitutions and storing the signature. If necessary code could be added to present a 'signature valid' badge.

Once we've finalised a signing process, the constitutions will need to be updated to reflect this.

XertroV commented 6 years ago

I agree that ultimately signing the constitutions would be better. However we also need to maintain key infrastructures and things like that. I've added some labels to help indicate this'll take a bit to figure out.

In terms of constitutions stuff - please don't remove anything. For most docs that's okay but constitutions are their own special thing. There's some legacy like this we'll need to just live with.

ACT was the first state/territory constitution we did and the commit hash thing was actually a PITA when revisions were made, so keeping it out is good, but if we can reference the hash of a constitution as the initial hash I think that'd still be good.

In terms of signing I think we can integrate PGP signatures/keys with git so that could fulfil some element of the signing process. Not sure if it works on merges though.

pwhipp commented 6 years ago

Sorry. I'll avoid editing the constitutions. We can probably do the signatures quite quickly and I think I can get them to present clearly on the website presentation. They are correctly invalidated by any edit or change to the relevant document. For infrastructure in this regard, the signature can be made by any valid entity so a group of people can have the same signing capability as needed.

Merges have no effect. If the signed rst file (or folder plus all its content) changes, the signature will be invalidated which is correct behaviour.

I agree pgp will be the best engine for this.

XertroV commented 6 years ago

All sounds good, and no worries re constitutions. Had a play with the makefile today so I could use python3 - feels easy to use bash + wget + pandoc to download constituitions on build

pwhipp commented 6 years ago

All sounds good, and no worries re constitutions. Had a play with the makefile today so I could use python3 - feels easy to use bash + wget + pandoc to download constituitions on build

I think it will scale well and give us the potential to do cool stuff with the signatures too in the long term. While I'm not sure how to effectively define signing requirements, we could allow alternative signatories and integrate delegation and a web of trust, enforced by githooks in the POT (and forks) so that the pull requests can be automated - sorta Signature Based Democratic Documentation ;)

XertroV commented 6 years ago

I think it will scale well and give us the potential to do cool stuff with the signatures too in the long term.

In the near term we could just use GitHub + PGP + Require Signatures (note: this isn't actually that great as it can prevent ppl from making PRs easily, which isn't really the goal)

In the long term it'll be blockchain based (which comes with signatures and all the other good crypto for free)