[Bf-committers] Python sandbox

Thu Mar 18 00:29:03 CET 2010

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.plus at 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 at blender.org
> http://lists.blender.org/mailman/listinfo/bf-committers
>