Isn't this a bug in Android for allowing an app to do this in the first place?

Well it basically contains 3 full operating systems (watchOS, tvOS, and iOS runtimes).

=/

LOL, yes sorry for the typo. I meant 2.7.4.

FWIW, the developer seed of Xcode 7.3.1 contains git 1.7.4.

Yes, Apple does need to react to git. Apple does that by updating to newer versions of git in newer versions of Xcode.

The issue here was that this announcement was made at a time when it was too late to include in the March 21 release of Xcode 7.3.

> they don't contribute to it since I'd imagine if they did contribute to it they would have known it was coming

Care to elaborate on why you feel that way? Apple has made attempts to contribute to git only to get shot down and rejected in the past, but most of Apple's changes have since been merged into git upstream or are available for anyone that wants to see them on github.

http://marc.info/?l=git&m=126819399002363&w=4
http://marc.info/?l=git&m=129105538829766&w=4
http://marc.info/?l=git&m=137514771912513&w=4
etc...

One difference between Apple's products and Linux distributions is that with distros, you actually get an update to git. With Xcode, you need to get an update to Xcode which contains git. git is used by Xcode for a variety of things and needs to be tested and verified to work correctly with the updated version of git underneath it. It would be bad to fix the vulnerability only to break Xcode's SCM system because of a regression in git.

Quality is a primary concern, and it takes time to test and qualify changes. Many other OSS projects recognize this and have a mailing list to discuss vulnerabilities between developers and vendors ahead of the fix landing and CVE publication. This allows vendors to prepare the fix for their pending releases instead of getting caught off guard by an announcement made at inopportune times that leaves them with no option for shipping a fix and hurting their customers.

2.6.6 was released at the same time as 2.7.4. At the time that this vulnerability was announced (March 15), there was no 2.6.6. 2.6.6 was released two days after the announcement of the vulnerability leaving just two days before Xcode 7.3 release (which obviously isn't enough time to build, package, test, ingest, and ship)

Testing? Qualification? I personally don't want Apple to release software without actually testing it first.

This issue was disclosed at literally the worst possible time for inclusion in Xcode 7.3. Had it been disclosed earlier, it's likely that it could have been fixed in Xcode 7.3.

There were no security issues addressed between 2.6.4 and 2.7.2. The vulnerability was fixed in 2.7.4, but I understand your confusion because upstream incorrectly advertised the issue as fixed in 2.7.1 on March 15 before actually fixing it in 2.7.4 on March 17.

What makes you say that? Vulnerabilities fixed in Apple updates are well documented:

https://support.apple.com/en-us/HT201222

On March 17. The final Xcode 7.3 seed had already been delivered to developers and was released in the app store two days later.

No, of course not. I'm saying that they should follow good security disclosure practices and coordinate with vendors like other open source projects do. If they're aware of a vulnerability, they should disclose it to vendors (Ubuntu, Fedora, RedHat, FreeBSD, OpenBSD, NetBSD, Oracle, Microsoft, Apple, ...) like other OSS projects do. X11 does this. Other OSS projects do this. Git does not.

The git developers announced this to the world before even they had released a version with the fix even though the fix had been available on master for a few weeks prior. There was no coordination with vendors (or even with themselves).

That's not at all true. Apple was definitely caught off guard, as was the rest of the industry. The issue was disclosed 2 days before the fix was released. It was reported to be fixed in a version of git that actually didn't even have the fix.

The version of git that is included on Xcode 7.3 was the latest stable version available when Xcode 7.3 went to beta. git 2.7.0 was released just days before Xcode 7.3.0 beta 1 was seeded to developers, and taking a new major version .0 of git at that time would not be appropriate (given that stability and reliability is a primary concern). The point is to deliver a mature, stable version of git to developers that works well and is well tested with Xcode's IDE SCM and Xcode Server. Users that want the bleeding edge version of git (which updates major versions about every other month) should install it themselves because it's simply not possible to include the latest version at Xcode GM and guarantee a well tested and stable experience to Xcode users.

Yes, there have been updates to OS X since December, but that's not at all relevant here for two reasons:
    1) OS X does not ship git
    2) The vulnerability wasn't fixed until late March (just a few weeks ago)

git 2.6.4 was shipped mid December, and Xcode 7.3 went to beta in early January (shortly after git 2.7.0 was released). Given that there were no security fixes in 2.7.0, 2.7.1, 2.7.2, and 2.7.3 and taking a newer version of git increases risk to Xcode due to changes in git, it's logical to expect that the version would not be updated to any of those versions after entering beta.

The git vulnerability was announced on March 15.
A fix was made available in git 2.7.4 on March 17.
Xcode 7.3 was released two business days later.

Obviously two days is not enough time for Apple to update Xcode's git to a new major version, thoroughly test it, ingest it into the Mac App Store, etc.

Why is Ubuntu releasing a software update worthy of an article?

So if the only licensed cables have HDMI connectors at both ends, what about all those HDMI DVI-D cables? Are all those "illegal" too?

This article has really one main point. American's are bad at math. They can't even invert a number that is in "miles / gallon" to figure out "gallons / mile" ... which I think is true... most Americans would fail 6th grade math.

Scratch (http://scratch.mit.edu) and Alice (http://www.alice.org) are probably your best bets. I've been teaching kids at this age level for the past four years, and the children have responded best to Scratch.

Both of these have the advantage of not frustrating students with syntax. Scratch has a better community built around it than Alice does, but it doesn't support things like procedures out of the box (it's event script driven). If you want to start teaching procedures, you should look into the BYOB fork of Scratch.

Alice has a better OOP model, but it's not entirely OOP.