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.p...@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@blender.org > http://lists.blender.org/mailman/listinfo/bf-committers > -- - Campbell _______________________________________________ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers