Chris S., I agree that in many cases an ounce of prevention is worth a pound of cure. I will also say that I feel that you're a self-motivated, capable person and you'd do good work anywhere in the org chart.
In my experince generally, Wikimedia is a more security-conscious and privacy-conscious environment than a lot of other orgs, and I think this is a net positive. The only critical security problems that I know about in my time with this project that created a lot of public concern were the OpenSSL vulnerability and some possible access to hashed passwords, neither of which resulted in compromised accounts so far as I know. I get the sense that most devs including volunteer devs are serious about writing code that is secure, reliable, and provides a good balance of privacy and openness. Speaking of pushing work to early in the development lifecycle, I am proposing to do the same for other elements of development via the proposed Technology Committee. We are thinking in similar ways. Pine On Tue, Jul 29, 2014 at 2:06 PM, Pine W <wiki.p...@gmail.com> wrote: > The everyday difference that this change makes may be trivial, but it makes > sense to me to think of QA (and Security Engineering) as being part of > RelEng. I doubt we disagree too much, but I'll put on my security evangelist hat and get on my soapbox, since you phrased it that way. It's not uncommon to see security placed (organizationally) as part of the release process. But while security reviews and security regression testing are important, I really hope that for MediaWiki, security isn't just a hurdle to deployment. I believe that security has to be a part of the entire development process to be effective. If the features aren't designed for security, security is always going to loose versus the need to deploy things that we've spent resources to develop. I think MediaWiki benefited a lot from having Tim be both the security evangelist and technical lead for so many years. So I try to spend a significant portion of my time working early in the development lifecycle, training developers and working towards more secure architecture, rather than focusing on the release process to fix all the bugs before we push something out. Sometimes that happens, and other times (like this week) I spend most of my time fixing issues after they are already in production. Core has been a good place to do that work from so far. _______________________________________________ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l _______________________________________________ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
