I laughed my way through this article. The best part was when he said he wasn't the only one, and linked to someone with legitimate concerns.
Don't want to use a bug tracker? That's fine. Use a TODO file in your directory if you need to put something aside.
Don't want to use VCS? That's REALLY stupid. Hook a clapper to a backup trigger. "I'm about to do something dangerous! (clap clap!)"
Why really stupid? Because you can argue git is too complicated, that it lets you do too many things, etc, etc. Great! You might be right. But if you're a beginner, you can get away with:
The long, laborious setup: git init
Saving changes: git add --all . git commit -m "This is what I did."
Hell, use a GUI. There's decent ones out there. But use something simple. Start HERE. This gives you an annotated history of what you changed and why. Do NOT argue that's some ridiculous process, because it will probably save you a significant amount of time within your first day.
Yes, you can set up a remote repository. Yes you can push, branch, merge, whatever the hell you want. But if it's just you, you're damn right that's too much process. So don't do it!
Attendance and evaluation are done directly into the SIS in most cases now. The biggest systems are web only, in fact. Many schools are tracking attendance by the minute to maximize their funding. Data is available to principals via their browser (or pushed in some cases) so they're aware of what's going on in their schools. Tracking of performance can be done across skills now, giving a much better picture of what the student needs help in rather than just "C-."
I'll admit I don't work on the lesson plans much, though I'm certainly aware a lot is going on.
Facebook can be pretty easily blocked at the router level. On the other hand, there's a variety of lesson plans and administrative tools used in education that can benefit from better connectivity.
If water is that good at dissolving plastic we're all in a lot of trouble. As for a new, plastic-eating bacteria? That's nothing to be concerned about at all!
Seriously, fish eating it terrible. But it is probably the least bad alternative, unless we're going to include "space aliens carefully harvesting it, while leaving sea life alone" on the list of theories.
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.
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.)
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.
This is a fascinating problem. I can see the feature being incredibly valuable, yet awful as it's currently implemented. Is there an approach to doing this safely?
Slashdot Mirror
My apps, which use AFNetworking, are not vulnerable. Precisely because I avoided 2.5.1 because I saw that commit go by and didn't like the look of it.
I laughed my way through this article. The best part was when he said he wasn't the only one, and linked to someone with legitimate concerns.
Don't want to use a bug tracker? That's fine. Use a TODO file in your directory if you need to put something aside.
Don't want to use VCS? That's REALLY stupid. Hook a clapper to a backup trigger. "I'm about to do something dangerous! (clap clap!)"
Why really stupid? Because you can argue git is too complicated, that it lets you do too many things, etc, etc. Great! You might be right. But if you're a beginner, you can get away with:
The long, laborious setup:
git init
Saving changes:
git add --all .
git commit -m "This is what I did."
Undoing changes before saving them:
git reset --hard
git clean -fd
Hell, use a GUI. There's decent ones out there. But use something simple. Start HERE. This gives you an annotated history of what you changed and why. Do NOT argue that's some ridiculous process, because it will probably save you a significant amount of time within your first day.
Yes, you can set up a remote repository. Yes you can push, branch, merge, whatever the hell you want. But if it's just you, you're damn right that's too much process. So don't do it!
Attendance and evaluation are done directly into the SIS in most cases now. The biggest systems are web only, in fact. Many schools are tracking attendance by the minute to maximize their funding. Data is available to principals via their browser (or pushed in some cases) so they're aware of what's going on in their schools. Tracking of performance can be done across skills now, giving a much better picture of what the student needs help in rather than just "C-."
I'll admit I don't work on the lesson plans much, though I'm certainly aware a lot is going on.
This isn't 1952. Technology can help.
Facebook can be pretty easily blocked at the router level. On the other hand, there's a variety of lesson plans and administrative tools used in education that can benefit from better connectivity.
If water is that good at dissolving plastic we're all in a lot of trouble. As for a new, plastic-eating bacteria? That's nothing to be concerned about at all!
Seriously, fish eating it terrible. But it is probably the least bad alternative, unless we're going to include "space aliens carefully harvesting it, while leaving sea life alone" on the list of theories.
Hippie doesn't usually extend to "caring at all."
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.
This is a fascinating problem. I can see the feature being incredibly valuable, yet awful as it's currently implemented. Is there an approach to doing this safely?
Yes. Won't someone think of the small developers?
Like Samsung.
-- A small developer.
And a bad month for Samsung.
Perhaps they are. It is remarkably difficult to secure a large code base.
Though I would hope that NFC is new enough that it would be coded securely right from the start.
Use Sun's site to check:
http://java.com/en/download/testjava.jsp
I doubt it's still installed after an upgrade, though.