@Derek: On 1/17/08, Derek Wright <drupal@dwwright.net> wrote:
@DragonWize: as I said before, your input on this thread is very welcome. Thank you.
I still disagree that reviewing and further improving the patches for security issues should be done directly under public version control. Seems like there's a little bit of an impasse here, and I'm not sure what to do to further convince you why I think it's a bad idea. I think I've been pretty clear about what I'm sure of and what we can't possibly know. All you've done in reply is assert that you don't think our concerns are valid (without evidence, which neither side has) and assert that you think maintainers would feel more comfortable doing it your way (which doesn't address the security team's concerns and just further adds to the list of things we don't know -- are maintainers actually more comfortable doing it your way or not?).
I have asserted my concerns are valid and you have asserted my concerns are valid but I have not said that everyone agrees with them ever. We don't know and I definitely am not the end source. So what do you if you do not know? You look at the possibilities and their outcomes and try to make an educated guess. Which is what I have done. I have showed both possible possibilities of committing code and not committing code in my view to further help us make that educated guess. The only reason given in this thread to date for waiting to commit the code is because hackers watch the cvs log. And I have made as clear as I can that if they are watching the logs (which they most likely are, to what is extent is debatable) then they know when the security hole is committed which is long before the fix is committed. I can not make it any clearer that, IMHO, that reason is full of false hope. If you have another concrete reason why not committing code is beneficial please enlighten me (if you have already mentioned it , I am sorry for missing it)
I'll make my own assertion to add to the mix: the reason so many developers aren't following this process isn't because it's so burdensome and difficult for them that they willingly chose to ignore it, it's because so few people actually know this is the process the security team wants people to follow, given a basically complete lack of detailed documentation or awareness about it.
Agreed as I noted in my last email. But I also believe that when you are trying to educate a large group of people that it is much more effective to teach them and for them to remember a simple 1 or 2 step process than a 12 step process riddled with a lot of dos and don'ts.
I was *not* trying to "market" the process. ;) I was trying to explain it, step by step, in developer-speak, not "marketing-speak".
This is a matter of vocabulary. Marketing or advertising something is a form of education. This is the way in which I have used the term. In that manner you were marketing it.
Now, the point is to either a) get everyone to agree this is the right process and carefully document it in the d.o handbooks (which anyone who wants to contribute could do, not necessarily the over- taxed security team itself), or b) make whatever modifications to the process we all think are worth making for the overall goal of a more secure Drupal ecosystem, and write up *that* process in the same way.
Again another form of education or marketing if you will. Education is definitely needed in many forms. In that respect I think there needs to be a simple more marketable form that we can easily disseminate to contributers every where they are found in addition to d.o handbook pages with full descriptions of the the process and FAQ. Thank you for your time, -- Alan Doucette Koi Technology, LLC www.KoiTech.net