[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
> 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
>>> is provided and accepted (unlikely!)
>>> You will be tried & hung by your peers. Be
> 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 , and other notable projects use
>> the Web of
>> Trust [4,5,6,12] created by GnuPG keyrings  to keep all
>> (think Operating System Extensions) secure, and tamper free
>> (There are other technical benefits too). The key
>> difference, is that
>> of guaranteed contributor accountability .
>> 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
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
Thanks, I look forward to his response.
have a day.yad
>>  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.
>>  New Maintainer website (and process from Debian): https://nm.debian.org/newnm.php
>>  Contributing to Ubuntu: https://wiki.ubuntu.com/
>>  GPG Web of Trust: http://www.gnupg.org/gph/en/manual.html
>> particularly: http://www.gnupg.org/gph/en/manual.html#WOT-EXAMPLES
>>  Advogato's Trust Metric http://www.advogato.org/trust-metric.html
>>  Wikipedia: Web of Trust: http://en.wikipedia.org/wiki/
>>  Wikipedia: GPG: http://en.wikipedia.org/wiki/GNU_Privacy_Guard
>>  A short history of GPG: http://lists.gnupg.org/pipermail/gnupg-announce/2007q4/000268.html
>> You will find libraries like GPGME much kinder to
>> efforts than some others: http://lists.gnupg.org/pipermail/gnupg-announce/2010q1/000298.html
>>  US Export restriction law (as recently touched a
>> developer): http://www.bis.doc.gov/encryption/ and http://www.bis.doc.gov/encryption/pubavailencsourcecodenofify.html
>> for US mirrors and hosting services.
>>  Electronic Privacy Information Center: http://epic.org/
>>  GnuPG archive keys of the Debian archive: http://packages.debian.org/lenny/debian-archive-keyring
>>  Debian's Web of Trust: https://nm.debian.org/nmgraph.php#manager
>>  The debian-mentors FAQ: http://people.debian.org/~mpalmer/debian-mentors_FAQ.html
More information about the Bf-committers