OS X 10.10 – Source Code | Hacker News Reader

OS X 10.10 – Source Code

opensource.apple.com

495 pointsbeltex144 comments

Open articleView on HN

I opened one package at random

http://opensource.apple.com/source/IOFWDVComponents/IOFWDVCo...

I see this:

#include <Carbon/Carbon.h>

//#include <Resources.h>

//#include <OSUtils.h>

//#include <Components.h>

#include "DeviceControlPriv.h"

#include "IsochronousDataHandler.h"

#include "DVVers.h"

#include <stdio.h>

#include <stdlib.h>

//#include <syslog.h>

// Debug messages

It's good to know that I'm not the only one who has commented out code in their shipping code:)

Trust me, you're among friends.

You have no idea. I know git is supposed to mean I can delete code without fear of losing it.

Still...

When I comment out code, I add a timestamp of when I disabled it. Then, when I come across commented code with a timestamp more than 6 months old, I go ahead and delete it. Best of both worlds!

Oh lord.

Best demonstration of Poe's Law right here.

Doesn't "git blame" take care of your timestamps for you?

no. vc will only take care if you have the history and know what you are looking. if you publish a final version only like this all that is lost. if you run a interpreted language you can't find the place of the old code while debugging at runtime.

there are many reasons to leave code comments besides neglect. though in this case it's neglect :)

Hmm what a nice extension idea for emacs comment-dwim.

You still can put one on top of that, like this:

    #if 20141031     // Date as a valid number != 0
      // Active code
    #else
      // Inactive code
    #endif

Helps documenting experimental alternatives, even without SCM.

This is really terrible practice. You should only do this if you really have no SCM available.

I'm talking about experimental alternatives. This is not for production code. And it's still better than just out-commenting code to deactivate it.

This is a similar to an idea that David Schnepper talked about at Velocity Ignite this year.

It's only a five minute presentation but it blew me away and I'm keen to give it a try for real at some point. Video here:

https://www.youtube.com/watch?v=29UXzfQWOhQ

I like this alot, would anyone be keen to collaborate on a simple ruby gem to implement this 'tombstone' method?

great idea, I would definitely throw it into all of my ongoing projects.

I put this together today, would value any feedback and/or contributions:

https://github.com/lewispb/tombstone

Wow, simple and short, but has already given me a ton of ideas. Saved and shared with our IS department too.

Funny how this is kinda Halloween-ish.

Great share, thank you!

This is thought provoking; I shared my reactions here: http://djwonk.tumblr.com/post/101423057084/tombstones-as-a-w...

I wonder how they tombstone CSS.

I like that idea. I remove commented code when it's "old enough" but know how long it's actually been could be really helpful.

I would be awesome if there were a plugin (for your favorite text editor) for that. It should be easy to add automatically and remove when you uncomment it.

Perhaps not a bad idea. One advantage to David Schnepper's suggestion (in the video above) is that the tombstone is executable code, which can lead to metrics and even automated code removal. Buyer beware!

Glad to hear this isn't an odd concept. When I see others have commented out code in our codebase, I do a quick git blame (Sublime Git ftw!) and if it's from the previous year I'll just delete it.

We aggressively delete code. Hg/git will have it if you ever need it.

We never have.

This. Though I do often wonder how often I re-type the same thing, because I can't simply uncomment, simply because it's easier to type it out than it is to go hunting through the history. Maybe I should try to make a Git history "redone undos" script or something.

When I actually think about it I realize it's probably very nearly never. But it's hard to shake the suspicion :)

It's just more convenient to keep the code in, otherwise you'll have to look it up again which takes more time... (and effort, we're developers after all)

This was the one thing that my CS professors drilled into my head most: you have source control, why would you comment?

You only make your source control more valuable by not commenting out code; since you can then search for its presence more easily. Good advice, all around.

I think it's genetic :) Some people are "code pack rats". They're afraid to delete anything.

When you put a lot of time and effort into adding code in all the right places to provide for functional, helpful debugging, tearing it all out afterwards is just going to make you add it back in again when debugging something else down the road.

Even if you tear it out, it's way more work to try to pull it all back out, line by line, and re-implement it than to comment it out and leave the actual debugging statements in #ifdef blocks that the pre-processor will pull out anyway.

I'm the converse, I break other rules, but I really don't commit commented code (well I have some demo code commented somewhere, but it's runnable code).

Commented code, yuk.

This is bad practice, at best it shows a lack of confidence in what you've written. At worse it shows you don't understand what's going on.

Version control shows the evolution of design, if you are leaving in dead code you need to take a step back and think about the real solution.

Does anybody know what Apple uses internally as their version control setup? I did some Google searching that seems to suggest they use Git, but I'm curious if anyone knows more.

When I was there it was a healthy mix of CVS, SVN and git.

Engineering wanted to move to git, so I would assume they are on the path to 100% git, annnnd.... probably already are at this point.

There is still some SVN floating about but its primarily git

There's a great deal in Perforce too; the P4 gui tools are excellent, by the way, at illustrating changes in source over commits, and are incessantly in use.

I've heard this so much. Usually from people who reinvent the wheel five times over.

I've never seen anyone dig through VCS history to gain a better understanding of code. And since presumably things change because the understanding evolves, I'm not even sure what the thought process is that would lead someone to do that.

You comment out code because your understanding might not be perfect, you might want the option to easily roll-back, or even have a reminder that a particular change was made. You'll remove it in the next revision or two.

So yeah. I've heard this before. It's complete and total nonsense IME.

> I've never seen anyone dig through VCS history to gain a better understanding of code.

git bisect, git log, and git blame are all indispensable tools. To counter your anecdote, I use them all the time and see others do so.

There's really no reason to leave dead imports in a file.

> I've never seen anyone dig through VCS history to gain a better understanding of code.

I'm actually going through the ancient CVS history of Mozilla Firefox in order to learn about a relatively poorly understood piece of code that's still in there to this day:

http://mikeconley.ca/blog/2014/07/07/docshell-in-a-nutshell-...

and

http://mikeconley.ca/blog/2014/08/10/docshell-in-a-nutshell-...

You never wonder why particular lines of code happen to do exactly the things they do, in the exact order they do them, when your intuition would tell you that it would be a third as many lines if only the code called this or that utility function, or that it obviously doesn't handle the particular corner case of a new bug report? You must work on unusually well commented code bases then; I wouldn't get anything done without git log -p... at a minimum you will quickly find out which generation of maintenance programmer added the odd code in question and what (if any) bug it was intended to fix, so you don't break that use-case. Well, unless you're out of luck and the first generation of them lost the first 5 years of SCM history, that is...

No. If the intent behind the source code you're actually looking at is not apparent, then realistically, looking at it's history is probably equally useless.

If there aren't tests or specifications to cover the code, I generally assume any bugs are because of a lack of understanding and proceed from there.

Scrolling backwards through history and looking at progressively more naive or prototypical implementations isn't going to tell me anything except the code was likely underspecified IME.

Comments are infrequent, but when I write them, they're usually to try to clarify particularly complex implementation detail. Not to communicate requirements. Comments aren't the ideal place for that IMO.

> I've never seen anyone dig through VCS history to gain a better understanding of code.

One of my favourite interview questions:

    A bug is found where given a specific series of user
    interactions an error is raised. You search for this error
    in code and you find that the error is raised in a very
    old module which was written in a different style from
    the main codebase by a developer who has long since left
    the company. From a quick look around you see that this
    code is very complex, and probably quite important. It's
    obvious that it will take quite a bit of time to 
    understand what's going on simply by just reading the
    code in the module where this error is raised.

    Your job is to fix the bug. How do you approach this
    problem?

At my company digging through VCS (and our ticketing system) in order to gain a better understanding of code is a very common.

Edit:

I think if you're leaving commented out code for history's sake, you're Doing It Wrong. I disagree with the GP's idealism as much as you do, however. My beef with it is that if you're checking in commented code, you're obviously not reviewing your own diffs. It means you're likely to commit minor changes which were made for debugging purposes.

    // comment this, just to get this stupid module out of my way.
    //ensureNobodyDies();

Ticketing system sure. If you have the full history you'd get the original requirements hopefully, and revisions or issues along the way.

VCS. Maybe it's just a Web vs Other development thing. The history of an Action in Rails is going to be someone using mass-assignment unsafely. Or a dozen stylistic tweaks. Or implementing a pattern. Or removing it.

It's about the worst possible way I can imagine to attempt to understand requirements.

What I do find helpful is "git blame", and just talking to the person who implemented it. And if they aren't available, then hopefully someone who was there at the time, and involved with the feature, is. At least I have a time-frame.

As a last resort, if no one has any clue what's going on? Scrolling through VCS diffs would be an act of desperation perhaps. But I'd much rather look for tests. Automated or a Manual Test Plan. A Specification. Or just use common sense.

At the end of the day it's most likely that I'm tasked with this issue because the original implementation was a scheduling compromise, or the original developer just couldn't think of how to make it simple, so they made it complex.

Actual complexity is rarely justified by requirements I find. Unless I'm the one writing it of course. ;-) Then it's absolutely the only sane way to implement it and you just need to try harder to understand. Duh.

> Actual complexity is rarely justified by requirements I find. Unless I'm the one writing it of course. ;-)

I appreciate your humility, and I largely agree with your approach. You'd probably do quite well in my interview.

With respect to actual complexity rarely being justified, I'm presently a team lead for a system which involves fairly precise modeling of some very piecewise real world processes under very tight performance constraints. There are so many things we just can't generalize, either because there's no clean abstraction, or because abstraction comes with too much inefficiency. We try to keep our processes from smelling too much like old stale spaghetti, but unfortunately some things are just simply complex, and sometimes in the face of such complexity the most elegant and/or performant solution can make purists cringe.

I thought Carbon was already deprecated in favor of Cocoa - does that header mean it's still being used in the Yosemite?

Carbon applications are deprecated, but there are C-based APIs still in use that fall under that umbrella term, such as Keychain Services.

Understood. Thank you.

Exterminate it with a flamethrower

This inspires me to update my script that converted opensource.apple.com into Github repos [0] (even creating the repo using the Github API). It needed more work because some of the Apple source releases are messed up and include another copy of the source tree in a directory at the root of a tarball!

I asked Github if it was OK to upload the tens of gigabytes of source that the entirety of opensource.apple.com is and I got a "Sure, why not?" response. =)

I think the last time I updated these repos was around 10.7 or 10.8

[0]: https://github.com/Apple-FOSS-Mirror/

Edit: I was always wondering how I could manipulate git such that anyone could checkout my scripts and create identical git repos (same commit hashes and all) with a single command. I am somewhat hesitant to update the repos now because it would involve rewriting old commits since I haven't solved this problem yet.

That's a brilliant idea. Couldn't you test a newer version of your script against a new branch?

Yeah... once I find it on my old backups. =) Ironically, my script that produces git repos was not itself version controlled. Lesson learned (for the umpteenth time). I wasn't comfortable putting it public due to sloppiness and I didn't yet have my own GitLab server. I now have the latter and am motivated to fix the former (put the script itself on Github). =)

Let me know how you go. Contact details are in my profile. I've got way too many projects to finish right now, but I'd like to boot XNU in a VM at some point.

Yup. Great idea. Along with "github-backup" like tool (I use this one - https://github.com/joeyh/github-backup) then I could spend days browsing and reading :)

For those interested, a great github repo with the OSX Libc is here:

https://github.com/aosm/Libc

Very easy to switch between OSX releases with the tags.

For those of us who don't know what we are looking at, and just see the title of "OS X 10.10 - Source Code", is this just Darwin, or is there more here than that?

The kernel is in the xnu folder, this is a bunch of the underlying system, not just the kernel, but it's not the case that you can compile this all and get a working OS X Yosemite desktop (at least, I don't think you can but correct me if I'm wrong!)

I think I did compile a kernel on 10.6 or 10.7

My understanding (which may be out of date) is that this is the complete OS but without the GUI layer - it is the kernel, init system, shell, and user-space CLI utilities. It does not include the GUI shell (Aqua), the GUI libraries (Frameworks in OS X terminology), or GUI applications (iTunes, Mail, Safari etc.).

Does this mean if you compile this and get it to work, you can get something like XFCE or KDE running on it?

Sure. People have been doing that since 2000.

http://www.puredarwin.org/

Keep in mind that there are a lot more Frameworks other than just GUI related ones that aren't present as well. They have a lot more tools missing than just the "glitter"

It would be more accurate to say that it's most of a fairly random subset of the OS that was made open source back in the day - there's very little of newer projects (regardless of what 'layer' of the OS they're at), including ones that replaced older ones, some old stuff is gone, and I'm not sure it ever really counted as complete.

Some examples:

- The main kernel is open source (although not 100% identical to the version in OS X), but many kernel extensions are closed source, including quite basic stuff like disk image mounting.

- In one open source kernel extension I'm interested in, IOUSBFamily, functionality has been randomly disappearing in favor of empty .cpp files. Like several of the opensource releases, it doesn't actually compile...

- A version of CoreFoundation (C level API) is available, but not the full thing. The Objective-C runtime is available, but the core Objective-C libraries have never been.

- libxpc, which is rather low-level functionality added a few releases ago, was never open sourced; launchd is gone in this release, but before that it didn't compile, thanks to missing xpc headers.

- Bootloaders: BootX from PowerPC was open source, but the x86 EFI stuff was always closed source.

- libm is gone this release. cctools may be gone. Some libSystem libraries such as malloc and pthread were separated out in a previous release, but not open sourced; they're back now, though.

libm has been gone for a while, unfortunately: https://news.ycombinator.com/item?id=8502968

Thanks for expanding on that - it is disappointing how Apple are releasing less and less with each iteration.

I think it's everything but XQuartz.

Here's a diff between the 10.9 package list [0] and this one: https://gist.github.com/anonymous/014e71ac38a4776811f7

Few changes, but some interesting things pop out, like the addition of libmalloc and libpthread and the removal of memcached and securityd.

[0] http://opensource.apple.com/release/os-x-109/

The removal of launchd is a bit of a bummer.

especially since someone had been working on porting it to FreeBSD for their Summer of Code project.

It's already running.

https://github.com/outbackdingo/launchd_xml https://github.com/rtyler/openlaunchd

Works on 10.1

Not running 10.10 at the moment; did they switch to something else, or just not release the source?

It's still used, they haven't released the source.

launchd is still the launch agent for 10.10, they probably just removed the source for this version.

Ah, the freedoms of permissive licenses... better than proprietary at least.

they wrote launchd. Even if they released it under GPL, as the copyright owners, they would have the freedom to make future releases closed source.

10.10 ships launchd 2.0 which is a complete rewrite: https://twitter.com/launchderp/status/528053818156527616

Apparently the launchd code got rolled into xpc, which is closed source.

I guess this puts the quiet removal of launchd from macosforge.org into perspective.

http://web.archive.org/web/20120609100559/http://launchd.mac...

Unfortunate timing since it was finally getting a working port on FreeBSD.

Diff isn't the world's best way to look at this. e.g. the source for securityd was still released, it's just under a different directory now (Security-57031.1.35/securityd/).

Nice, I'm glad they finally released libmalloc source after they separated it from Libsystem (or was it in Libc? Eh, one of those). It was not in the 10.9 releases when the split happened. I think most of libSystem.dylib (and its sub-dylibs) are once again open source. =)

Not really, I still can't seem to find the SSE assembly versions of many functions that have been missing since OSX 10.9:

http://stackoverflow.com/questions/25505371/where-did-osxs-x...

A great, although sad post about the state of building (booting) Darwin: http://superuser.com/a/634080

Bummed they didn't fix the bug I submitted in vfs_syscall. In fsetxattr when key values are too long it returns EPERM instead of ENAMETOOLONG as described in the man page :(

Bug is not present in setxattr: http://opensource.apple.com/source/xnu/xnu-2782.1.97/bsd/vfs...

The procmail source is something else https://opensource.apple.com/source/procmail/procmail-14/pro...

For a real head trip, read Sendmail's.

Why is iOS only disclosed up to version 6.1.3? https://opensource.apple.com/

I believe Apple stopped releasing any source for iOS at that point. The open source projects they pull from are BSD/MIT which permits and encourages closed source usage.

Presuming OS X pulls from the same licensees, why do they release those revisions but not iOS?

Wild guess: while iOS' version of XNU is often one major version ahead of OSX, there is no way for 3rd party developers to write kexts on that platform (beyond jailbreaking). Maybe they don't want to help jailbreakers.

WebCore and JavaScriptCore are LGPL, so they can't stop providing the source code for their mobile builds. I sent Apple a request for disclosure a couple days ago. In a week or so if I haven't gotten anything I will start escalating.

Can you not get to that stuff through the WebKit repo?

edit: Looks like you can: https://github.com/WebKit/webkit/tree/master/Source

This is where I was digging to find whether or not JavaScriptCore would still work with WKWebView. Spoiler: it won't.

Yeah, you can get the webkit source through the webkit repo.

however, since it's under lgpl, any source you write that uses webkit must also be shared. this is why some of EA's code is published: http://gpl.ea.com/

That's GPL, not LGPL. LGPL only requires you to release the source of the part you used, nothing that links with it.

I still haven't got a clue what needs to be done if I used a component with, say MIT license which in turn uses a dependency lib that is LGPL licensed.

That components vendor of course then has to make the source of the LGPL dependency available on request. But what about me?

What would I need to do if I wanted to sell a closed source product that uses this MIT licensed component which is of course totally permitted my the MIT license. Would I have to stop using this MIT licensed component unless I also want to provide the source code of a dependency lib that I might not even be aware of?

If your distributed object code includes a library that is under the LGPL, then you must also make the source of that LGPL library available on request, and users should be able to change that LGPL library in your project with their modified version of that LGPL library. So, if I remember well, you can either (a) use dynamic linking so that the user can replace your version of the LGPL library with their modified version, or you can (b) provide object code that can be linked with their modified version of the LGPL library.

IANAL, but are at least two cases of "was not aware of": if that MIT licensed package mentioned the LGPL dependency, you could and should have been aware of the dependency, and I think you must mention it in your license, and provide the source on request.

If, on the other hand, the MIT licensed product doesn't mention the dependency, and you cannot be expected to have learnt of it elsewhere, you should be of the hook, both ethically and as far as damage lawsuits go. As soon as that "expected to know of" changes, you must change your license and provide the source on request (or remove the dependency or stop shipping your entire product)

Of course, that is an opinion and just theoretical. In practice, who knows what will happen? That is one reason large companies are/used to be worried about using any source that doesn't ship with extensive disclaimers. Large companies are expected to spend more effort researching these things. That lowers the threshold for "should have known". They generally also have more money. That makes them more open for lawsuits if they are found to walk in a gray area.

>> That's GPL, not LGPL. LGPL only requires you to release the source of the part you used, nothing that links with it.

Nothing that dynamically links with it. Static linking makes your code part of the library and requires source.

No: the mobile version of WebCore is different, and for example comes with binary object blobs (which is sufficient for LGPL compliance) for source code that Apple refuses to provide as open source. I wish I had been here earlier to correct this misinformation :/ (though I'm also glad I've gotten in the habit of not checking Hacker News after I comment). Note the libWebCore_{Sim,armv7,armv7s}.a that is provided in the WebCore source repository at opensource.apple.com.

http://www.opensource.apple.com/source/WebCore/WebCore-1640....

It is also simply not sufficient to say "here is a repository with a lot of code in it": you have to be able to specify what exact code was used for the build (which is what I care about, as I'm constantly trying to analyze the version of WebCore on the device: I have no interest in compiling my own copy or building my own browser), and it is not the main WebCore repository's job to keep tags or branches around for specific versions of iOS that Apple distributes.

>It is also simply not sufficient to say "here is a repository with a lot of code in it": you have to be able to specify what exact code was used for the build

Does the LGPL really specify that? IIRC the license is pretty vague and that seems way too specific to hold up in court.

The LGPL references the terms of the GPL in the context of the library released under the license. For both versions 2 and 3 of the GPL, it states that build instructions must be made available [1].

[1] https://www.gnu.org/licenses/quick-guide-gplv3.html#less-sou...

> it is not the main WebCore repository's job to keep tags or branches around for specific versions of iOS that Apple distributes.

They're all at http://trac.webkit.org/browser/tags/. You can map from the LC_SOURCE_VERSION baked into one of WebKit's frameworks back to one of those tags.

OK, at some point I see they started adding AppleWebKit/# to the User-Agent. On a device running iOS 6.1, I am seeing "536.26". In WebCore.framework it reports "6536.26" (at some point they dropped the leading "6" from versions).

It looks to just be missing the final version component, as even versions of iOS 6.0.x have that same version. So, I went and got the code from opensource.apple.com and started bisecting for the version... the code is totally different.

I don't think you understand the situation here: the iOS version of WebCore is not developed in public, and lots of parts of it are redacted. Even in the code dumps from Apple on opensource.apple.com, some of the code is a .a file.

To demonstrate this, as maybe it still isn't clear what is going on, Apple released iOS 6.0 in September of 2012. Apple released the source code for the iOS 6.0 version of WebCore, and it includes a special "platforms/ios" folder.

This folder contains files like ClipboardIOS.h. If we look in the WebKit source code repository, this file did not get "upstreamed" until May of 2013. You simply can't tag something if it isn't even in the source code repository.

http://trac.webkit.org/changeset/150049

(Interestingly, when Apple did finally provide this source code, they also provided the corresponding ClipboardIOS.mm: they did not on opensource.apple.com, and instead provided ClipboardIOS.o as part of libWebCore_armv7.a.)

I hadn't considered that you were focused on historical versions of WebKit as I was thinking of the latest shipping versions. You're quite correct about this for historical versions of iOS. Since then the iOS port of WebKit has been upstreamed into the WebKit SVN repository, and the WebCore content in the tags correspond exactly to the source that's built.

But the LGPL requires you that you can (principally) exchange the LGPL shared libraries by your own ones. (source: http://en.wikipedia.org/wiki/GNU_Lesser_General_Public_Licen...: 'Essentially, if it is a "work that uses the library", then it must be possible for the software to be linked with a newer version of the LGPL-covered program. The most commonly used method for doing so is to use "a suitable shared library mechanism for linking". Alternatively, a statically linked library is allowed if either source code or linkable object files are provided.'). Is this possible on iOS?

So, in practice, the LGPL doesn't actually let you change the code out, because the bootloader is allowed to make it impossible to modify the binaries, this being the reason for GPL3. On a jailbroken iOS device, though: yes, you can swap out WebCore if you manage to compile it (good luck ;P).

Good! I hope they’ll respond to you within a reasonable time frame.

It doesn't encourage, it merely permits.

It does encourage you to upstream your changes so you don't have to hire developers to keep up with upstream's improvements and deal with merge hell.

Does Apple upstream any of their changes?

The license absolutely doesn't encourage you to share. The technical complexity of managing a project might, but the license is purposely designed so anyone can take without giving.

in recent years even MS is releasing more meaningful open source code than Apple (eg. asp.net vnext, PCL) or I'm missing something

They've also added support for Docker, contributed code to Linux and are including a package manager in Windows 10. The world is turning upside down :)

Not sure they're releasing any OS code publicly though :-) internals still have to be somewhat guessed/reverse engineered at.

There are strings attached, but it is not that hard to get access to the Windows source code: http://www.microsoft.com/en-us/sharedsource/default.aspx

Yeah, I'm for sure missing launchd and memcached. But I suppose they've got their reasons.

memcached is still open source. Apple's just no longer redistributing source for it (probably because it's no longer included with the OS).

What version control does Apple use? Is this the same that is being hosted in the linking site as well?

Any idea what's up with the cert on https://opensource.apple.com/?

It works fine for me. AFAICT the cert they use is okey.

[Fingerprint: 92 D3 F3 46 0E BA A5 FE D5 5E C8 AE 19 59 82 57 85 FE AE 88 A5 9D F7 BE FC 47 89 38 5F BC 4A E9 (SHA-256)]

Now will someone figure out a terminal command to turn off the MacBook Pro display for Yosemite?

Like the following: http://osxdaily.com/2011/09/14/disable-the-internal-screen-o...

Do they not create bootable, installable images of Darwin anymore?

From memory, this is the first release of the Darwin source in ages, but https://opensource.apple.com/ looks to have been updated.

http://www.puredarwin.org/ looks abandoned, and OpenDarwin disappeared long ago - http://www.applematters.com/article/opendarwin-dies-a-lonely...

> From memory, this is the first release of the Darwin source in ages

Ages? https://opensource.apple.com/ looks like it has for a while, except for the addition of 10.10 (I grab CFLite, libclosure, libdispatch, and objc4 whenever they're made available after a release).

Not in a very long time. If memory serves, Apple last released a bootable image for one of the Darwin 8.x releases.

Does anyone know what they're using Twisted for?

A bunch of the OS X Server stuff, including calendars, feeds, etc.

Really. I'll have to dig into it to see how they're using it.

swift is not open source?

Some claim it will be, though there's been nothing official from Apple yet.

im pretty sure the official comment was 'we don't know yet, but we'd like it to be if it makes sense'

Not currently. But it's a development tool, and not a part of OS X, so it wouldn't be listed here anyway. For instance, this page has Clang, GCC, Git, etc.: http://opensource.apple.com/release/developer-tools-51/

https://github.com/ksm/SwiftInFlux#open-source-possibility

and they fixed a few Integer overflows - int size = inCapacity * sizeof(dictEntry); + if (inCapacity > (UINT_MAX / sizeof(dictEntry))) + return false;

+ unsigned int size = inCapacity * sizeof(dictEntry);

And the good old shellshocked bash version 3.2 http://opensource.apple.com/source/bash/bash-94.1.2/version....

You have to look for the vulnerable code, not just the version string. Supposedly it has already been patched.

a patch was released for OS X versions below 10.10 only, so I would assume it should be applied to OS X 10.10: http://support.apple.com/kb/HT6495

I would assume that the patch has already been applied to the shipping final version of 10.10.0; installing system packages designed for older OSX releases sounds dangerous.

Just install a newer bash with homebrew ¯\_(ツ)_/¯

That's what I did, before Apple even released a patch for Mavericks.

That's not shipping or has patches added:

---------

rutina:~/git/bashcheck@master$ uname -a

Darwin rutina.local 14.0.0 Darwin Kernel Version 14.0.0: Fri Sep 19 00:26:44 PDT 2014; root:xnu-2782.1.97~2/RELEASE_X86_64 x86_64

rutina:~/git/bashcheck@master$ ./bashcheck

Testing /bin/bash ...

Bash version 3.2.53(1)-release

Variable function parser pre/suffixed [__BASH_FUNC<..>(), apple], bugs not exploitable

Not vulnerable to CVE-2014-6271 (original shellshock)

Not vulnerable to CVE-2014-7169 (taviso bug)

Found non-exploitable CVE-2014-7186 (redir_stack bug)

Test for CVE-2014-7187 not reliable without address sanitizer

Found non-exploitable CVE-2014-6277 (lcamtuf bug #1)

Not vulnerable to CVE-2014-6278 (lcamtuf bug #2)

does this mean we can compile Yosemite from the code here and install it on a modern Mac?

Or is this just the Darwin kernel code?

Are the aqua/user interface layer also included here?

Any CONTEXT related to this source code would be greatly appropriated.

It seems those are only the free/open source components, that are used by OS X.

Vast portions of code that makes it usable are missing; as someone above stated, Aqua is missing as well as core items like disk image mounting etc.

I tried many years ago to use Darwin in the "haha I can run Mac OSX but not actually buy a Mac" sort of idea - it was an exercise in hard work (as I hadn't a clue what I was doing) and what I did managed to get to boot wasn't massively useful for "real" work (a CLI with no windowing layer) like development etc. or anything you do day to day.

Quite interesting nonetheless, but not massively useful.

It's not intended to be used standalone, it's there for other OSS developers to be able to use.

Hi Ubuntu! How do you think about this?

Just by glancing over the code overall looks like a poorly structured and inconsistent code, lacking centralized coding guidelines or practices. Pretty scary for a shipping product to have code like this.

This is a good step into making Star Trek law the real law.

for a second there i was hoping to see that they had merged https://github.com/fix-macosx/

Reply on news.ycombinator.com