[development] Think there's a security problem in your module? Here's what to do.

[DragonWize]

@Derek:

On 1/17/08, Derek Wright <drupal at 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