I really like Jonathan's idea. Perhaps some sort of distributes/crowd sourced 'plugin center' for blender, that relies on a web of trust. I think that is a great idea, and unless the community thinks it's a horrible idea, I will submit a GSoC proposal on it.
~Leif Andersen ---------- So Much to Learn, Such Little Time http://leifandersen.net/2010/02/03/so-much-to-learn-such-little-time/ On Wed, Mar 17, 2010 at 16:59, jonathan d p ferguson <jdpf.p...@gmail.com>wrote: > hi. > > > I feel that I must raise the issue of *trust* again. It is extremely > relevant to this issue, and many others now facing many FOSS > communities, particularly blender. > > The problem is running *untrusted* code. The trust in this case, > really comes down to trusting the script's author. > > Perhaps it is time to implement a robust trust model. > > Implementing a robust trust model does not require a switch of > languages, nor does it require crippling python. What it *does* > require is a robust, authenticated trust model that cannot be spoofed. > A central authority is one such model, if very carefully created > (think Certificate Authority). The Web of Trust is another, and one > that I will articulate here for those unfamiliar with it. A Web of > Trust model is usually more robust than a central authority model, as > it is not subject to a single point of failure like the Certificate > Authority model. GnuPG (aka PGP)'s Web of Trust model is the most > robust I've seen. > > Perhaps a GSoC proposal to investigate this, and possibly implement a > Web of Trust model? (This isn't a proposal, yet, but it could develop > into one. I am happy to help advise a student for the GSoC--- if there > is sufficient interest by the community.) > > > > > > > Here's how I imagine a Web of Trust would apply to the "python > scripts" problem in Blender: > > The basic idea in a Web of Trust is that blender users and developers > will have GnuPG keys. Already trusted content will run automatically--- > based on some trust-threshold setting (this is built into GnuPG). The > bf-keys will be the most trusted--- as all developers and many users > will sign those keys. Content (read, programs) will be > cryptographically signed by the content creators. If the trust values > of those creators exceed the trust threshold set by the end user, then > that content will be able to run, otherwise, the default action is to > prevent the script from running. Eventually, all trusted scripts will > run without a prompt. > > Again, the most accessible, and widely deployed trust model I know of > is the Web of Trust--- which I raised in my previous email about the > new Python script approval process. This model uses GnuPG keys and the > social networks of users who authenticate each other. The model > applies to the development, and distribution phases of the blender > life-cycle. > > > > Here's how the basic user-story would go: > > Goal: Download an untrusted script, written by someone you have not > encountered before, and run it. > > Requirements: For the script to run, you must trust it. That trust > will be expressed by the trust value in the Web of Trust model, you, > as you, the end user, set. You have a GnuPG key. The script-author > also has a GnuPG key. The author signed her script with her key. > Blender knows where your GnuPG key is. For convenience, both keys are > in a centralized key-server. Blender will automatically fetch her key, > to verify that she did, in fact, sign the script (this process is > called validation). > > Actions: Download her script. If enough of your *trusted friends* > trust the script-author, then, depending on your trust-settings, the > script may be run. If not, then you will be prompted to: 1. run the > script (with an appropriate warning*), and/or 2. accept the author's > key for future trust. 3. One may even opt to sign the developer's key > later on if she proves to be trustworthy. After passing these > authentication, and authorization stages, the script will run (be > given access). > > *Please note, the default action is NOT to run. It is imperative to > make sure that no denial-of-service prompting will occur. Users must > *explicitly* allow the script to run. > > These operations could be integrated into blender, bringing blender > into the social application sphere--- with a robust trust model for > developers and users alike. While Blender would not be the first > project to use the web-of-trust model, it will be the first > application with this level of atomic integration. A good model to > evaluate is that used by Debian and Ubuntu. Both of those > distributions employ a Web-of-Trust to protect the integrity of the > distribution, and to discourage malware. That is the goal here also, > as blender will be a distribution of tools, as opposed to a "single- > application." > > > > Possible changes to the blender project (this is just an example > set--- to show the idea): > > * Blender developers will all have GnuPG keys, and (depending on the > outcome of decisions about the process) they will all sign a "bf-keys" > GnuPG keyring and/or key depending. Think code-signing key. > * Blender executables, and releases will be signed with said bf-keys > key. This key will be *the most trusted* because many developers and > users will trust it (either by signing the key, or accepting it). > * Blender will integrate the GnuPG libraries as appropriate (GPGME for > example). > * Blender's User Interface will expose appropriate trust mechanisms > for all trusted keys ie: a list-outliner like view with trust values > for each listed key, and the ability to arbitrarily set the trust > value of keys you have signed. This will include the ability to sign > other keys, and to upload your keys to a centralized blender-GnuPG > keyserver. > * End-users will need to be educated about the new processes. > > > > Documentation on how this might work: > > GnuPG: http://www.gnupg.org/ notably: > http://www.gnupg.org/features.en.html > > * A short history of GPG: > http://lists.gnupg.org/pipermail/gnupg-announce/2007q4/000268.html > You will find libraries like GPGME much kinder to integration > efforts than some others: > http://lists.gnupg.org/pipermail/gnupg-announce/2010q1/000298.html > > * Wikipedia: GPG: http://en.wikipedia.org/wiki/GNU_Privacy_Guard > > * GPGME, a library for integrating GPG: http://www.gnupg.org/gpgme.html > > * Web Of Trust: GPG Web of Trust: http://www.gnupg.org/gph/en/manual.html > particularly: http://www.gnupg.org/gph/en/manual.html#MANAGEMENT > and > http://www.gnupg.org/gph/en/manual.html#WOT-EXAMPLES > > * Wikipedia: Web of Trust: http://en.wikipedia.org/wiki/Web_of_trust > > * Advogato's Trust Metric http://www.advogato.org/trust-metric.html > > > Associated tools and examples: > > * GIT: http://git-scm.com/ > > * Git is very good at this kind of integration, down to the level of > the source-code. This is because git identifies changesets as SHA1 > hashes which can be cryptographically tied to a GnuPG signature. See: > http://kernel.org/pub/software/scm/git/docs/git-tag.html > > Debian and Ubuntu: > > * Debian: New Maintainer website (and process from Debian): > https://nm.debian.org/newnm.php > > * Contributing to Ubuntu: > https://wiki.ubuntu.com/ContributeToUbuntu#Contributing%20to%20the > %20Universe%20Repository%20(MOTU) > > * Debian's Web of Trust: https://nm.debian.org/nmgraph.php#manager > > * GnuPG archive keys of the Debian archive: > http://packages.debian.org/lenny/debian-archive-keyring > > * The debian-mentors FAQ: > http://people.debian.org/~mpalmer/debian-mentors_FAQ.html<http://people.debian.org/%7Empalmer/debian-mentors_FAQ.html> > > Given that blender is hosted *outside* the USA, the following is only > relevant to developers implementing the trust model who are US Citizens: > > * US Export restriction law (as recently touched a blender developer): > http://www.bis.doc.gov/encryption/ > andhttp://www.bis.doc.gov/encryption/ > pubavailencsourcecodenofify.html for US mirrors and hosting services. > > * Electronic Privacy Information Center: http://epic.org/ > > Thanks. > > have a day.yad > jdpf > > > > _______________________________________________ > Bf-committers mailing list > Bf-committers@blender.org > http://lists.blender.org/mailman/listinfo/bf-committers > _______________________________________________ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers