Odd question.

I don't know about three days, but certainly under a week, which is completely normal in free software. Proprietary vendors generally want between six months and two years, but free software vendors and projects very rarely ask for more than a week or two delay before publication.

In fact, Linus famously tells people not to tell him about any security issue you want kept secret for more than a week, as he will just go ahead and fix it.

Odd, I don't know why you're picking on me, but I assume "Android Kernel" is marketing-speak for "Linux", in which I've reported found and fixes dozens of flaws over the years.

As you're so interested, here are some from the last month or two that you can take a look at.

CVE-2010-3080, A use-after-free in snd_seq_oss_open
CVE-2010-2960, A to-userspace dereference in keyctl_session_to_parent.
CVE-2010-2954, Kernel panic and to-userspace dereference in AF_IRDA sockets.
CVE-2010-3067, Various problems with aio (things like aio_submit())

The coverity results I've seen in the past are generally very low quality with a high density of chaff. I haven't seen the report they're talking about, but would be surprised if there were any noteworthy findings with any significant security impact. The only report I've seen them publish that had any convincing vulnerabilities was in 2006, where they found a verifiable privilege escalation in XFree86 (due to a pretty horrendous typo).

I'm a little saddened that you so readily associate me with Windows security, where as I consider myself primarily a Linux security developer, but I guess I'm flattered that where I spend my time is so important to you.

(perhaps a little creepy, though).

You didn't elect me your doctor either, but I'm sure you would like me to tell you if you water supply was poisoned.

Actually, his comment was entirely accurate.

I've reported dozens of critical vulnerabilities in Microsoft software over the years, and I still have multiple open cases with Microsoft security, this particular case wasn't as simple as you have assumed. I would not be so presumptuous to explain the ethics of your work to you, but evidently you believe you're qualified to lecture me in mine.

If I were to read the sensationalised lay-press coverage of your latest publication or project, would it prepare me to write a critique of your
work?

I'm more concerned about invisible sharks with lasers on their heads.

I assume you have examples? Because I've seen several claims of this sort, and so far they've all been rubbish.

Are you a linguist and statistician? If not, you lack the skills to make that determination.

Furthermore, there are several things described in the Book of Mormon that are quite clearly supported by history, but only discovered by scientists long after the Book of Mormon was published.

That's anecdotes not evidence. Furthermore, all major religions have those kinds of anecdotes, so they are not particularly convincing. I'm not enough of an expert on all those fields to counter every one of those anecdotes; I know enough about some fields to know that the Book of Mormon cannot be what it claims to be.

If you have an iPhone you can get the authenticator for free as an app, and they have said they would like to bring it to more platforms in the future (presumably android, blackberry, minmo and the other major smartphone os's).

I discovered this bug (check the credit section in the advisory), so can explain. The bug is in parsing a component of TTF files, which are handled by the GDI kernel subsystem in Windows. Anything that tries to load fonts can be used to exploit this vulnerability, as they will eventually reach this code, Internet Explorer just happens to be the easiest way to reach it remotely.

Other browsers _are_ affected, the difference is that there's only one level of indirection before the vulnerable code in Internet Explorer, and at least two in other browsers. This is because IE supports EOT files directly, which via TTLoadEmbeddedFont() are decoded and passed straight to GDI, where as other browsers take a TTF input, convert it into an EOT and then pass that to TTLoadEmbeddedFont, so you have to convince three different chunks of code your input is valid (the browser, t2embed, then gdi), instead of just two in IE.

If you use any browser that support @font-face on Windows (Safari, Firefox 3.5+), you should still patch and reboot.

Actually, it is possible to map at NULL in Windows, which is just as plagued by NULL pointer dereferences as Linux is.

Try this:

BaseAddress = (PVOID) 0x00000001; // (1 & ~PAGE_SIZE) == NULL
RegionSize = 0x1000;
NtAllocateVirtualMemory(GetCurrentProcess(), &BaseAddress, 0, &RegionSize, MEM_COMMIT | MEM_RESERVE, PAGE_EXECUTE_READWRITE);