[Bf-committers] Python sandbox
jonathan d p ferguson
jdpf.plus at gmail.com
Wed Mar 17 23:59:45 CET 2010
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
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
More information about the Bf-committers
mailing list