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

jonathan d p ferguson jdpf.plus at gmail.com
Sun Mar 7 21:26:16 CET 2010



Thanks for your response.

On Mar 7, 2010, at 11:00 AM, mindrones wrote:

> --- On Sun, 3/7/10, jonathan d p ferguson wrote:
>> Is this a general "I"? Or really the role of a "package
>> maintainer"?
> At the moment Brandon is taking care of scripts, but generally all  
> of those with
> bf-extensions svn access can do that if the script is in trunk/ and  
> really malicious.

OK. I'm asking these questions for the purpose of clarifying the roles  
you've created in the community, and to articulate why a web of trust  
is a good idea. Perhaps no clarification is needed.

>>> 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.
> I think it was meant to be ironic :)

So do I. Yet, in policy-making, irony is unwelcome. I call it out  
because some may read the above statement as a challenge. "How  
difficult is it to write well concealed malicious code? How hard would  
it be to get it past the maintainers? etc..." Isn't the goal to  
prevent the development of malicious code in the first place? People  
come and go in FOSS communities for all kinds of reasons... I argue  
that formal accountability can only help reduce the chaff of  

> But yes, I doubt that you can trust again a code that has  
> consciously written some
> malicious code no?

Yep, and that's why I'm asking if you had considered a formal web of  
trust model, and if not, to consider it.

>> 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?
> It's been a lot of work discussing about it and then establishing  
> this, I really
> hope we don't change it now that it's all setup... :)

I'm sure it has, and I understand and respect the work you have all  
done to arrive at an agreeable process. I wrote to express my thoughts  
on the matter of accountability and trust when it comes to trying to:

> On Mar 5, 2010, at 9:16 AM, Brendon Murphy wrote:
>> ... provide a safe, friendly & simple system
>> to handle trusted external scripts and plugins ("extensions") & their
>> development.

Many very smart people have spent decades figuring out how to handle  
trust in distributed communities. I wrote to suggest that the Blender  
community, like others, may wish to build on that work.

> Also, everyone is on 2.5 now, jesterking will be away for a while so  
> I think that
> there arent many human resources to do something more elaborate for  
> a bit.

OK. Thanks for the heads up. I understand that developer resources are  

> Meanwhile we can trust opinions from the incolved extensions  
> developers, which is
> a good start I think.

Indeed. My comments are forward looking to the days when Blender sees  
greater adoption as it matures. As I'm sure you all know, 2.5 will  
catapult that adoption curve forward. I am already seeing a greater  
willingness on the behalf of students and Indie professionals (in the  
game industry) to adopt Blender. This will lead to a shifting user base.

I commend all of the Blender developers for the huge increases in  
usability, portability, and flexibility of 2.5. As the number of users  
and developers increases, the question of trust becomes more relevant.

My point is that formal systems to discourage abuse have been  
developed, are entirely GPL, and available for integration--- IF  
desired. That integration may occur now, it may occur later when the  
need is more apparent.

>> Thanks for all the hard work!

> By the way, Brandon told me he will be offline for a week for  
> connectivity problems,
> I guess he will take care to answer this thread when he'll be back  
> eventually.

Thanks, I look forward to his response.


have a day.yad

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

More information about the Bf-committers mailing list