[Brion Vibber wrote]:
As I understand it, this was fixed a few hours ago,
and was present for just a
few hours before that; so if you updated from SVN trunk in the last day, make
sure you update again. :)
Yes, I hadn't looked at the code at all until after it was fixed, and I want to say
thanks and kudos most especially to Rob Church
for getting the fix in so quickly.
Looking back at what happened, the timeline roughly went like this:
2006-06-23 13:15:59: Bug accidentally introduced by small change.
2006-06-23 19:30:00: Current SVN checked out by me.
2006-06-23 19:45:00: Test script started, and after a few minutes reports unexpected
results.
2006-06-23 20:55:00: Me narrowing down the problem.
2006-06-23 20:05:00: Details sent by me to devs.
2006-06-23 20:13:57: Bug fixed and checked into SVN.
So within 7 hours it was accidentally introduced, found, reported, and fixed - which I
think is an amazingly quick cycle ... and of
these steps, the slowest part of all was me! ;-)
[Tim Starling wrote]:
This sort of thing really doesn't need to be
reported to wikitech-l.
Whoa! Time out for a reality check.
Let me say this very simply: YOU DON'T GET TO MAKE THAT DECISION. The ONLY person who
gets to choose how a bug is reported is THE
PERSON WHO FINDS IT.
If I find a bug, then I, and only I, get to choose what to do with that information.
Now, there are a very wide variety of responses to finding bugs.
Some of them include:
1) Do nothing. I could find a bug, and just sit on it. I don't have to tell anybody.
(For example, I never bother reporting bugs to
Microsoft any more).
2) Report it to bugzilla.
3) Report it to the developers directly via email.
4) Report it to a technical mailing list about that product, with very limited or no
details.
5) Report it to a technical mailing list about that product, with Proof-of-Concept code.
6) Mail it straight it to bugtraq, together with Proof-of-Concept code.
7) Post it anonymously on a script-kiddies bulletin-board.
8) Sit on it, and store up exploits until there is critical number (e.g. 10), and then
combine them into some kind of MediaWiki-worm
that knows how to attack all 10 exploits + change a few words / numbers in random
articles, and then release it anonymously without
warning at 3 PM on a Wednesday afternoon at peak server load, and then sit back and watch
the resulting car crash.
That's 8 possible responses, from the nice to the incredibly antisocial, from the
indifferent through to the illegal. There are more
responses, and of course some of the responses can be combined. But all of those responses
have one thing in common: None of those
decisions are made by you.
Now, as a general rule I choose to do option 3 (mail the devs) for non-security related
bugs, and option 3 + option 4 (mail the devs
+ mail a heads up to wikitech-l) for security bugs that have a working Proof-of-Concept
attack.
I choose to do this because I think it is most positive and constructive thing to do with
that information. It gives those with the
capacity to fix the problem the details they need in order to know how to fix it; and it
gives those who may be affected by the
problem the information to know that they will probably want to update shortly and to be
wary of exploits, whilst not giving
attackers the details they need to be harmful. In particular, I think mailing wikitech-l a
quick email with details of which
version(s) are affected, the general category of the security bug, but no specific
details, is useful. The reason it is useful is
because if someone chooses to run a particular tree (in spite of suggestions that they
shouldn't), they will know that there is a
particular type of security issue, and then they can update to keep themselves protected;
Also the users of those sites can be aware
of potential exploits until the problem is resolved. Last but not least, if _I_ was
running an affected MediaWiki install, then I
would want to know: so telling people this to me is a case of treating others how you
would have them treat you.
Now, if you or anyone else doesn't like those heads-up notices, then there's a
simple answer: Don't read them! I don't know about
you, but I get hundreds of spam emails per day, and I'm quite capable of completely
ignoring them, and not reading them. So if
heads-up notices about security issues in software you're involved with bother you,
then don't read them. That's YOUR response,
which YOU GET TO CHOOSE.
Of course, in my personal opinion, the best response is probably sending a reply like this
to wikitech-l:
-------------------------------------
Thank you for your MediaWiki bug report. We believe the issue that you reported has now
been fixed in SVN revision 14990
http://mail.wikipedia.org/pipermail/mediawiki-cvs/2006-June/015970.html ).
Updated releases of the stable tree are released periodically as tarballs, and release
announcements are sent to the
MediaWiki-announce mailing list. Current snapshots of the development tree can be grabbed
by doing an svn checkout/update of the
current development source code.
Thank you for your report and for helping us to make MediaWiki even better.
-------------------------------------
Sending that to wikitech-l in response to a security heads-up on the same list gets you
several things:
1) It acknowledges that you got the original bug report.
2) It confirms that there was a problem.
3) It tells everyone that the problem is now fixed.
4) It sends the clear message that "this software is well maintained and we respond
promptly to security issues".
5) It tells any affected site admins which release / version they need to update to order
to be protected from the problem.
6) It thanks the reporter - because although you mightn't realise it, finding these
types of problems can be hard work, and a little
thanks never goes astray.
[Tim Starling wrote]:
Further to that, I would appreciate it if Nick would
commit his testing
scripts to SVN, and document them fully. It would be easier if we could do
this testing before we commit, rather than go through all this rigmarole.
I shall be happy to email yourself and Brion an updated version of the script that I'm
using (you'll have to check it in, as I don't
have commit privileges). I'll endeavour to get it you today, but failing that some
time this week. As with all software I'm sure it
can be improved, but it's probably better to have something more current checked in to
the tree than the old version that is there
currently.
Please note however that the script mightn't be quite what you think it is: For
example, I didn't have a test for this specific
IpBlockList problem ready to go just waiting for this exact problem. Rather I had a script
that generates tests, runs those tests,
and if it fails keeps the tests. So I ran it for a few minutes, it generated a specific
IpBlockList test that failed, and then I
took a closer look at the generated test that failed, and said "Oh, that's
interesting". So it's a test generator and runner and
result-checker, not a set of predefined static tests.
As such, as a constructive suggestion, one possibility might be to add a cronjob similar
to how parserTests gets run nightly and the
results are mailed to wikitech-l. Currently the script runs until stopped with CTRL-C, and
it prints out progress information as it
goes. So as a possibility, you could perhaps update it to accept some command line
parameters (such as adding a silent mode that
only prints out real errors to make it less chatty, and adding something so that you could
specify to run for a specific amount of
time [e.g. 1 hour] instead of indefinitely, and maybe also a maximum number of errors to
report). Then the resulting nightly output
could be emailed to wikitech-l, or you could set up a separate private mail alias if you
wanted (I'd be happy to be included on
this, as it may or may not require some explaining at first about what it's upset
about, and it might require a bit of tweaking to
get the right level of information from the script). That way you'd get an additional
different and complementary type of continuous
nightly testing to help catch any regressions or other problems.
All the best,
Nick.