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

[Campbell Barton]

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:
> hi.
>
> Luca:
>
> 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
> anonymity...
>
>> 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
> finite.
>
>> 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
> 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
>
> _______________________________________________
> Bf-committers mailing list
> Bf-committers at blender.org
> http://lists.blender.org/mailman/listinfo/bf-committers
>



-- 
- Campbell