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 _______________________________________________ Bf-committers mailing list [email protected] http://lists.blender.org/mailman/listinfo/bf-committers
