[Bf-committers] Python sandbox

jonathan d p ferguson jdpf.plus at gmail.com
Wed Mar 17 23:59:45 CET 2010


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  

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- 

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

* 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:

* 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

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/ 
pubavailencsourcecodenofify.html for US mirrors and hosting services.

* Electronic Privacy Information Center: http://epic.org/


have a day.yad

More information about the Bf-committers mailing list