I've reported three security issues. Two of them were fixed in the next release — the third was fixed in the next release after that (but I reported it two days before the next release).

So I have to call bullshit. Report security issues through channels, they'll get fixed. Post them to your blog or on a forum, Apple will never see them.

It's left implied (I think) that he didn't notify the vendor at the same time as everyone else, just that the vendor noticed the public notification.

If I'm wrong and he explicitly looped Apple in, then I'd consider that responsible (or responsible enough, at any rate).

That's a good point, too. Disclosing a weakness is more reasonable than a ready made exploit.

Thanks for your reply. I've softened on this since making that comment. I think there's a huge grey area for responsible disclosure. A week ahead of time? A day ahead of time? I'd consider these fairly grey, but whatever. But I still think not disclosing it to Apple at all and relying on them picking it up through the grapevine is pretty irresponsible.

I've reported three security issues to Apple. While the issues I reported were relatively minor (one was a design flaw in Time Machine, the other a buffer overrun in one of the image decoders; I don't even remember which, and the final one in the DMG handling), I wasn't at all happy with how Apple handled them. I received no email until a couple weeks later when they asked me how I'd like credit. They got patched in the next version of the OS, but in both cases I was left with several weeks of wondering if they'd even read my bug report. The design flaw was easy for the user to workaround (you just had to make sure to remove insecure apps from your Time Machine backup), so I mentioned the workaround a few days after reporting it.

But I can't imagine not at least telling Apple. In fact, one of the bugs I reported was a longstanding bug I found documented in public. I was just the first one to report it to Apple. It got fixed two weeks after I reported it. I just think it's absurd that we accept the bystander effect when it comes to computer security.

(I originally wrote this reply having forgotten of one of the issues I reported, so if there's anything left that implies only two that's why.)

I didn't see that in the article. Can you point it out? (Seriously if this is true, I really want to know.)

Do you have any evidence this was introduced in 7.0.6?

"Mandt said he did not disclose the issue to Apple"

We really need to stop paying people — directly or indirectly — for irresponsible disclosure.

I was a Palm programmer at the time. I have to call "bullshit."

First, you can set the password to much longer than 4 characters.

Secondly, any parent can tell you that even without "wipe after 10 failed attempts" turned on, the iPhone will not allow you to enter PINs continuously. You'll start getting increasing delays fairly quickly, including delays that are quite long.

It would if full disk encryption was on and the user didn't leave their encryption key/password.

No, CVE-2014-1266 is 10.9 and 10.9.1 only. You're right about it also applying to iOS 6, but that's what the person you're replying to already said.

There's no contradiction there. You are running a seed of 10.9.2, not 10.9.2.

I'm more curious if Apple will put out a fix BEFORE 10.9.2 ships; rumours still peg 10.9.2. a few weeks away.

The source is available; how does "security through obscurity" apply at all?

Um, sure there is. Search for SSLHashSHA1.update; it's in the second group of them.

10.7 probably isn't vulnerable, as it predates iOS 5 (which doesn't have this flaw).

If 10.8 is vulnerable, the suggested upgrade would be 10.9.3 anyway. (10.9 has the same requirements as 10.8, and is a free upgrade.)

I would like to see an article that explains which versions are vulnerable, however.