Again, not asking for what you can not provide. You must, however, do
your part.
Right *there* is where it is born! Right at your development kernels. It
may or may not survive up to the big market. However, being at the
source level, it is your duty to a) resolve the source-level issues; b)
put affordable efforts in order to prevent one known issue to arrive at
the end point.
There is obviously room for suffering from this delay. It's really
small, however, if you understand that this is not enough time for
widely spread exploits to be in the hands of every corner kid. Not.
Thus, consider the following: how many computers are likely to suffer
from one bug that has been advised (marked as "security related" in your
bugzilla), and, one week later, fixed? Now, how many computers are
likely to suffer from one bug that has been advised and fixed 8 weeks
later? A lot more, I presume.
Ok. Now, imagine this scenario: one bug that has never been identified
as "security relevant" is assigned and/or fixed by your people.
Remember, your list is open to public. Do you have a clue of how many
individuals keep watching every bug/fix, with a "security antenna"
turned on, expecting for the right bug to show up and... not receive the
attention it needs so they can do whatever they want, for the amount of
time they please? Several.
Now, tell me, how many computers are likely to suffer from the last
scenario; the one that you cultivate?
Just mark it. No big deal.
Those who can see, and quickly exploit it, do not need your mark. They
will figure it out right after it was assigned and an exploit will exist
in the wild not after you fix the bug. So, let's work for the smallest
pain. Right?
--t
--