[Bf-committers] Blender Projects: Blender Extensions Add-Ons (scripts/plugins).
ideasman42 at gmail.com
Sun Mar 7 22:03:52 CET 2010
just omit references to malicious developers from any documents.
If a developer gains our trust by contributing and then does something
obviously malicious we can deal with it when it happens.
So far hasn't happened, IMHO its a waste of time to discuss it.
On Sun, Mar 7, 2010 at 9:26 PM, jonathan d p ferguson
<jdpf.plus at gmail.com> wrote:
> 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
> Bf-committers mailing list
> Bf-committers at blender.org
More information about the Bf-committers