[Bf-committers] Blender Projects: Blender Extensions Add-Ons (scripts/plugins).

[jonathan d p ferguson]

hi.

On Mar 5, 2010, at 9:16 AM, Brendon Murphy wrote:

> The intention of this project is to provide a safe, friendly &  
> simple system
> to handle trusted external scripts and plugins ("extensions") & their
> development.


Thanks for working on this process. It is a good start on addressing  
accountability for the contributed scripts. Is obtaining guaranteed  
contributor accountability desirable?

Have you considered using GnuPG signature keychains [4,7,8] to create  
a web of trust [5,6]?

Among other benefits, requiring a web of trust at the outset will  
greatly discourage deliberately malicious code. Basically, all  
officially contributed code must be cryptographically signed [1,2,3].  
How bf-blender chooses to integrate this cryptographic code or process  
will have broader implications for the Blender project, and such  
implications should be considered with care.

> I will remove scripts from this svn at will if they don't meet  
> standards.

Is this a general "I"? Or really the role of a "package maintainer"?

> Any malicious code & the Dev will be immediately banned until an  
> explanation
> is provided and accepted (unlikely!)
> You will be tried & hung by your peers. Be Warned.

EEK! Wouldn't mentorship [13] be better? Does the Blender community  
actively punish contributors? My experience with the Blender community  
contradicts this statement. It is one of the most friendly, and  
encouraging, FOSS communities I know.

Debian [2,13], Ubuntu [3], and other notable projects use the Web of  
Trust [4,5,6,12] created by GnuPG keyrings [7] to keep all packages  
(think Operating System Extensions) secure, and tamper free [11,12].  
(There are other technical benefits too). The key difference, is that  
of guaranteed contributor accountability [12].

Perhaps the Blender project would be wise to adopt something similar  
for developers and script-writers?

I recognize that this suggestion potentially raises distribution of  
cryptographic code concerns, depending on how the blender community  
chooses to implement the process. Please correct me, but I believe  
that GnuPG is allowed in and exportable from most countries worldwide  
today [8,9,10]. (It is required by all Debian based distributions, for  
example).

Thanks for all the hard work!

have a day.yad
jdpf

[1] Git is very good at this kind of integration, down to the level of  
the source-code, btw. This is because git identifies changesets as  
SHA1 hashes.
[2] New Maintainer website (and process from Debian): https://nm.debian.org/newnm.php
[3] Contributing to Ubuntu: https://wiki.ubuntu.com/ 
ContributeToUbuntu#Contributing%20to%20the%20Universe%20Repository 
%20(MOTU)
[4] GPG Web of Trust: http://www.gnupg.org/gph/en/manual.html  
particularly: http://www.gnupg.org/gph/en/manual.html#WOT-EXAMPLES
[5] Advogato's Trust Metric http://www.advogato.org/trust-metric.html
[6] Wikipedia: Web of Trust: http://en.wikipedia.org/wiki/Web_of_trust
[7] Wikipedia: GPG: http://en.wikipedia.org/wiki/GNU_Privacy_Guard
[8] 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
[9] US Export restriction law (as recently touched a blender  
developer): http://www.bis.doc.gov/encryption/ and http://www.bis.doc.gov/encryption/pubavailencsourcecodenofify.html 
  for US mirrors and hosting services.
[10] Electronic Privacy Information Center: http://epic.org/
[11] GnuPG archive keys of the Debian archive: http://packages.debian.org/lenny/debian-archive-keyring
[12] Debian's Web of Trust: https://nm.debian.org/nmgraph.php#manager
[13] The debian-mentors FAQ: http://people.debian.org/~mpalmer/debian-mentors_FAQ.html