Hey, this is Cliff aka InSaneDarwin from PureDarwin Project we have a vm that is coming along nicely if anyone has seen our home page(http://www.puredarwin.org). We are looking for some help with our own ACPI/Platform Expert and so I/OKit Drivers if you guys are looking for some fun come join us.
If I understand correctly, this should be able to run on any Intel platform, so it's not bound to Apple-labelled hardware, right?
I'm asking because publishing cross-platform mobile apps is currently a hassle, as the iOS one can only be done from MacOS, which itself only runs on Apple hardware. As a consequence, I have an old Macbook lying around and dust it off everytime I make a release. A VM running anywhere would come a long way.
Also, I'm aware of hackintosh VMs, but it's a hassle to set up (and yeah, borderline legal, but I'm on borderline patience with all that inconvenience by now).
There are various companies online that give you remote access to a macOS VM running on Apple hardware, reasonably inexpensively. I use one for Mac & iOS builds. The one I use says in the contract that I am actually buying fractional ownership of the computer, along with hosting. I guess this gets around some Apple terms somehow.
Alternately, the VMWare ESXi bare-metal hypervisor is considered a legitimate "hardware" configuration that macOS will install under. If you have a spare server-grade PC laying about, or are willing to reformat a Linux server to put ESXi between it and the metal, it's a good option to get a local, "authorized" macOS VM.
This is not macOS. According to the screenshot of the latest build, it doesn't look like it even boots all the way to a shell. It is unlikely to ever help you with mobile app publishing.
"PureDarwin can run on VMware as well as real Intel-based hardware. We are successfully running a web server, have built hundreds of software packages with MacPorts running on PureDarwin, including ssh, apache2, tightvnc, Xfce, and others."
I personally haven't run it, but I think it's pretty usable if it can do the things mentioned above.
If I would need to run Apache, SSH, VNC - why would I go this difficult road? I can install Debian, Ubuntu or Centos, with desktop if I need it, and much more support online. What does PureDarwin offer that Linux doesn't?
The native macOS GUI has never been open-source. So pure open source Darwin (without any closed source Apple bits) has never been able to run native macOS GUI apps such as Xcode. Open source Darwin can only run non-GUI apps (text mode apps and daemons), and X11 GUI apps.
A really great niche that would play to your strengths is as a build environment for Mac software. The existing macs are terrible for this purpose, and really sometimes you want a rack mounted build server somewhere.
I don't follow Apple open source, so I have a lot of questions: What parts of MacOS are open source, and which are not? How is it licensed? Why is this on their website rather than GitHub?
As Apple is not developing this software in the public, it would not make sense to put it on GitHub or any other code hosting site. The usual approach is that Apple throws bits over the wall where you can pick them up months after the end-user release. And even these code drops will be thoroughly cleaned before, so that for example kernel sources do not contain any trace of support for ARM or anything else related to the iPhone – all of that is strictly closed source.
Software they take in from BSD, other open source projects, or some common Linux tools might also get patched. However, such patches are never actively submitted back to the projects, but only published on this website.
The sources published for macOS on this website are mostly licensed any variant of the BSD/MIT licenses, or the Apple Public Source License, or the GPLv2. Apple avoids the GPLv3 for legal reasons due to its patent clause. That is why they often ship only the most recent GPLv2 release and ignore all later updates, for example GNU make 3.81 or bash 3.2. There might also be some other licenses in the mix, such as the Artistic License for Perl and related software.
> As Apple is not developing this software in the public, it would not make sense to put it on GitHub or any other code hosting site
No, the reason they don't put it on GitHub is that they have no intention of participating in the community that made the software they are using.
All of these tools already have sites, communities, repositiories, etc. Apple could easily participate as many other companies do who also have proprietary patches. Apple actively chooses this over being a member of the software community it takes so much from.
Because Github is not equal to open source. It is a company out for profits like any other, why should Apple host what they choose to make open on that specific platform?
Apple also doesn't fulfill all of its GPL obligations (eg components used in iOS, example: libstdc++) and their OSS releases lag a month or more behind software releases.
I'm surprised to see you downvoted here. As a maintainer of an open source project, libgit2, which is GPL licensed and used by Apple, I am rather frustrated by Apple's behavior.
The source for libgit2 itself is not present on their opensource site, though they use it in Xcode. (Git itself is present, but is sometimes out of date compared to what they're actually shipping.)
I've emailed them about this and they offered to provide me the source they used. This feels like they're trying to do the bare minimum of compliance - and making even that nonobvious (since they have an obvious distribution mechanism.)
This complaint is not a claim that they're violating our license, but it's definitely not an ideal situation, and I'm sympathetic to your frustration.
libgit2 has a linking exception in addition to the GPLv2, which exactly allows what they are doing. This exception allows to link libgit2 without modifications in a program with absolutely zero obligations. It may not have been what you intended, but you cannot claim anything from Apple as you gave them permission to do that.
> In addition to the permissions in the GNU General Public License, the authors give you unlimited permission to link the compiled version of this library into combinations with other programs, and to distribute those combinations without any restriction coming from the use of this file. [...]
It allows people to link it in their non-free, proprietary software without any vitality on that proprietary software. It still requires them to make the source for the version of libgit2 that they are using available upon request.
> Apple avoids the GPLv3 for legal reasons due to its patent clause.
The patent clause is bad, but the anti-TiVoization clause is actually worse. According to that, if Apple accidentally ships any GPLv3 on iOS then they'll have to release their root signing keys to the world, which would be disastrous (it would destroy the security model of the OS).
> According to that, if Apple accidentally ships any GPLv3 on iOS then they'll have to release their root signing keys to the world, which would be disastrous (it would destroy the security model of the OS).
Stop spreading this FUD. They would not need to release their root singing keys in this case, just provide a mechanism to allow for other keys to be used (there are various ways to go about doing this without compromising security). The main requirement is that the compiled software can be run on the device.
It's not the position of the FSF who actually wrote the license. GPLv3 requires that users be able to install their own copies of the program onto the device. The device can allow a user-settable key in order to accomodate the requirement. No Apple keys need to be published.
No, he’s saying that if Apple chooses to trust the license author when they say that they interpret it in a specific way, they might get screwed if the license author changes their mind. Should that happen, a court of law would have the authority of legal interpretation.
And of course Apple is going to take the conservative position until a court rules on how to interpret the license; it's just not worth the risk to them.
Well, neither is Apple. And not just that, but Apple has incentive to spread misinformation about the GPLv3 (to discourage projects from using it so they can continue to use existing software without making their platform freedom-respecting).
User-settable keys also compromise the security of the device.
The most plausible approach is one outlined in another comment in this thread wherein you get a new key when factory-resetting the device and if you don't write it down it's gone forever, but even that approach will likely cause problems with Activation Lock. And in general it's risky to introduce stuff like this because the potential for unforeseen security compromises is very high, and the upside is very low (the number of people who'd actually take advantage of this is extremely low relative to the number of iPhone users).
the number of people who'd actually take advantage of this is extremely low relative to the number of iPhone users
That's only because we live in a world where phones aren't treated like the general use computers they are. MS+OEMs and Apple fought hard for decades to create an appliance mindset around what used to be a user-replaceable component, the OS.
We can just as easily imagine and try to build a world where it's just as easy to mix and match phones with phone OSes as it was to choose DR-DOS instead of MS-DOS.
> User-settable keys also compromise the security of the device.
Not if a physical modification to the hardware, a set of button presses, a hardware token or a fuse is needed to set said keys.
> And in general it's risky to introduce stuff like this because the potential for unforeseen security compromises is very high
There is little to no risk if physical interaction with the hardware is required for setting keys. If you have physical access and enough time, all bets are off anyway.
> ...and the upside is very low (the number of people who'd actually take advantage of this is extremely low relative to the number of iPhone users).
There are many people who dream of having the freedom to roll their own firmware on a particular device and it can be done without compromising the security of said device. This was not just about iThing users (who might/not take advantage of this), this was about people spreading FUD about the tivoization part of the GPLv3. Root signing keys don't need to be shared and the only requirement is that the user can take the sources, compile them and then run the result on the target device. As long as the OEM distributing the GPLv3'ed program gives a clear path for running the compiled code on the target device, then it is not a problem.
Which is why most systems that allow you to change the boot chain or otherwise mutate the chain of trust will clear the storage on the device (such as unlocking the bootloader in Android). And on Chromebooks, you cannot easily (read: without getting a flash programmer and doing it manually) subvert the boot chain and not let the user be aware of it (that's what developer mode is used for -- it shows a scary warning if the measurement and secure boot are disabled).
The reason nobody mentions this is because the solution is so trivial there's really no point in repeating it each time.
A walled garden OS doesn't do much to stop the abusive/spying household member problem. They can just beat you up until your give them your password, or spy on you and catch you entering it.
But they can't compromise the device without the victim knowing about it. Not all abusive relationships are violent or even directly coercive like that.
So much so that in your attempt to find any toehold to criticize it, your comment had to resort to coming up with scenarios that go outside of the system and rely on human vulnerabilities.
Assuming that Apple Legal is not lying (a big ask, as they have an incentive to spread FUD around GPLv3 and blame the license so to discourage projects from using it so they aren't forced to develop their own variants of more GPLv3 projects) there's also a possibility that they are misinformed or have come to a wrong conclusion.
Also, there's nothing stopping an opinion from a lawyer from being FUD. Apple Legal isn't your lawyer, they don't have a responsibility to tell you the whole truth or give you information that is in your best interest.
That's absurd. There's literally no reason for Apple Legal to lie. If Apple Legal was lying about the downsides of GPLv3, then that means there's no reason why Apple would care about software being GPLv3, which means there's no incentive to try and convince people to stop using it!
Also, it's not like Apple Legal is telling anyone outside the company about this. Apple's not releasing any public statements asking people not to use GPLv3. So how exactly are they supposed to be discouraging its use when the people using it don't know what Apple Legal thinks about it?
> There's literally no reason for Apple Legal to lie.
Yes there is. Apple doesn't want to use GPLv3 for other reasons (they don't want users to have full control over their machines -- which they've proven time and time again with the iThings). But rather than saying "sorry, we don't want you to be able to control your machines" (which would be bad PR) they spread rumors about "GPLv3 means your software cannot be secure against certain attacks".
> Also, it's not like Apple Legal is telling anyone outside the company about this.
Hence this whole comment thread is a discussion about theoretical views of Apple Legal. My whole point is predicated on "someone actually knows for sure that this is the opinion of legal".
> they don't want users to have full control over their machines
Oh come on. You sound like a caricature now. "Not having control over their machines" is not a goal and it makes you sound like a crazy conspiracy theorist to claim it is. Security is a goal, and unfortunately security often conflicts with having complete control over the device. But that's different than saying Apple actively wants to prevent users from having control over their devices.
> they spread rumors
No they aren't. Apple doesn't make any public statements about GPLv3, period. Apple can't possibly be spreading rumors if they're not talking to people.
> My whole point is predicated on "someone actually knows for sure that this is the opinion of legal".
I do. I know for sure this is the position of Apple Legal. Which is why I said this was their position in the first place.
> "Not having control over their machines" is not a goal and it makes you sound like a crazy conspiracy theorist to claim it is.
I agree that security is a primary goal of Apple. And many of the restrictions have a mostly valid security justification. But "ability to have full control of your machine and be able to replace components" is clearly not part of Apple's goals. So they don't spend any time thinking about solving the problem with that constraint.
What security do you get from not being able to replace the window manager? Because if you want to claim that "Apple prioritises users being able to control all parts of their machines, and security prevents this from being possible" then you have to give a security justification for every un-configurable restriction.
> Apple doesn't make any public statements about GPLv3, period. Apple can't possibly be spreading rumors if they're not talking to people.
Well, we're talking about it right now aren't we? I'm aware they didn't make any public statements, but this whole discussion is pointless if we are just going to say "I know this is their true opinion and they have no reason to lie to me because they didn't say it publicly, therefore [contentious statement about GPLv3] is effectively correct and there's no point in discussing this further".
> I know for sure this is the position of Apple Legal.
You know that this is what Apple Legal told you, or someone who knows someone at Apple Legal told you. Unless you're part of Apple Legal in which case you've now made a public statement about GPLv3.
"Having complete control over their machines" being a non-goal is not the same thing as "not having complete control over their machines" as a goal. And trying to spread malicious rumors about GPLv3 only matters for the latter, not for the former.
> What security do you get from not being able to replace the window manager?
Well, you could argue that a third-party window manager could be snooping on all of the content visible on your screen (that otherwise isn't available to third-party apps) and could be doing whatever they want with that potentially-sensitive info. But that doesn't even matter, because the real answer here is "it's a massive amount of work to support third-party window managers, since the window manager is such a crucial and low-level and highly-integrated part of the system, and there's no motivation for Apple to expend that tremendous amount of work, especially because they'd likely end up with a far-less-stable system as a result".
> Well, we're talking about it right now aren't we?
We are, yes. Apple isn't. No matter what I say on the subject, that doesn't mean Apple is spreading rumors. I don't work for Apple.
> This is the very definition of a rumor.
You're free to accuse me of spreading rumors if you want. And I can't very well deny that because I can't provide any verification, but this interpretation of GPLv3 is a fairly common interpretation so I don't see that there's any reason to doubt it.
But you can't accuse Apple of spreading rumors because people like me are making statements about this.
> Well, you could argue that a third-party window manager could be snooping on all of the content visible on your screen
And Apple's APIs let you snoop on those events anyway (that's how the semi-third party window manager-managers work), this is not an argument...
> because the real answer here is "it's a massive amount of work to support third-party window managers, since the window manager is such a crucial and low-level and highly-integrated part of the system, and there's no motivation for Apple to expend that tremendous amount of work,
...so what you're saying is "they don't want to put the effort into being able to replace core components of the system"? Because that's what I'm saying. I'm just saying it in a less charitable way than that.
> but this interpretation of GPLv3 is a fairly common interpretation so I don't see that there's any reason to doubt it.
It's only a common interpretation if you believe the rumors about Apple's view (and you're not the only person spreading them). FSF does not make that claim. Effectively everyone who uses GPLv3 doesn't make that claim (as far as I know). The only people that I've seen make that claim are people who say "this is the justification that Apple told me off-the-record but since they said it off-the-record we can't discuss it's merits". Do you see why I would suspect that this rumor spreading is co-ordinated?
We went through this bullshit back with UEFI and GRUB in the Linux community. The agreement was that GPLv3 is fine so long as it is possible to replace the keys (and wiping the machine on key replacement is what you want to happen anyway, so that's fine and it solves the security issues). If you want to start claiming that it's a "common interpretation" you need to show that there is a larger community than the Linux community that uses the GPLv3. And you won't find one. Because it's not a common interpretation in the community that uses that license.
> It's only a common interpretation if you believe the rumors about Apple's view
Why do you keep talking about rumors? And why do you keep talking as if this is somehow unique to Apple? I'm pretty sure Apple's not the only company that believes this. In fact, I have no idea why the FSF would even claim otherwise; Apple's interpretation seems to be perfectly in line with the entire point of the anti-TiVoization clause.
If Apple were to accidentally ship GPLv3 software on iOS 11, under whatever interpretation you subscribe to, how is Apple supposed to remain in compliance with GPLv3 without releasing their root signing keys? Remember, we're talking about shipping this on existing devices, not on some hypothetical future device where they can add extra user-swappable keys to the bootloader.
You keep insisting that Apple's interpretation is wrong, but you haven't provided any alternative interpretation.
> If you want to start claiming that it's a "common interpretation" you need to show that there is a larger community than the Linux community that uses the GPLv3
That's a catch-22. There isn't a larger community because GPLv3 is toxic to companies. Nobody else is going to create a larger ecosystem of GPLv3 code because doing so basically means turning into Linux.
> Apple's interpretation seems to be perfectly in line with the entire point of the anti-TiVoization clause.
Apple's interpretation of "we cannot design a system where you can have signed binaries [where you can replace the root signing keys] that complies with the GPLv3"? That's not what the GPLv3 changes meant.
Please just read the GPLv3 and make up your own mind, this is getting ridiculous. No reasonable interpretation of that section means that it is not possible to design a system that has binary signing and complies with the GPLv3. Apple's current system could not comply without releasing the root signing keys, but that's because they decided to design their system that way.
> If Apple were to accidentally ship GPLv3 software on iOS 11 ...
We're not talking about them accidentally shipping it. We're talking about them deciding to not update to GPLv3, and the justification being "security". Obviously accidentally shipping it would cause them issues, but that's
> Remember, we're talking about shipping this on existing devices, not on some hypothetical future device where they can add extra user-swappable keys to the bootloader.
You might be talking about that. That's not what I was talking about. I was talking about them designing products that explicitly don't allow user-swapping is the problem, and that there is no fundamental reason why you cannot have a secure system that allows user-swapping keys.
Of course a current device would be insecure if the root signing keys were released, because their threat model doesn't take that into account.
> There isn't a larger community because GPLv3 is toxic to companies.
I work for a company that releases GPLv3 software all the time. I've started projects that are GPLv3 as an employee. It's only toxic to companies that don't want to comply with free software licenses.
Nobody said Apple is incapable of designing such a system. But that's not the system they have today. It seems your entire argument is based on a hypothetical alternate universe where iOS allowed for user-swappable keys. But that's not what this thread was about, so your entire argument is completely moot.
> This is all just more FUD.
Please stop calling things FUD just because you don't like it.
> But that's not what this thread was about, so your entire argument is completely moot.
I guess you were in a different thread than me. The discussion started with saying that "they don't use GPLv3 purely because of security concerns as they cannot have a secure system". I outlined that yes you can, you said that "currently Apple's system doesn't work that way" and now you're saying that discussing whether or not it is possible to create such a system is off-topic.
Maybe I just misunderstood what you meant, but if that's the case then it still doesn't justify you broadly making incorrect claims about the GPLv3. You should say something like "Because Apple doesn't have the ability to replace the keys by the user, they cannot use GPLv3 as that would make their system insecure". You cannot omit the first part as it makes the statement incorrect.
> Please stop calling things FUD just because you don't like it.
"GPLv3 is toxic to companies" is FUD. It promotes fear through the use of the word "toxic", it promotes uncertainty by challenging a well-established license with vague concerns, and it seeds doubt in whether the license will be toxic to their company. As many companies do use and ship GPLv3 software and aren't being killed by this hypothetical toxicity, this is FUD.
It just so happens that I don't like that you said it, but that's because I don't like people spreading FUD. ;)
What does it matter what the legal position of Apple is? Of course if they aren't interested they would say that, wouldn't they? I'd say what matters is the licence text and FSF's statements in that matter.
I guess in that case they would just break the license rather than complying with the "penalty" clause. As in "we never agreed to this license, we just used the source illegally. So sue us for that." - and if they are sued, settle for a million or so, peanuts.
Now, I don't know if there is any provision in US law that makes you automatically enter a binding contract if you use code that is accompanied by a license file. It is certainly possible, as you demonstrate intent to enter the agreement. But OTOH, this would be too easy to abuse. Just sneakily replace the LICENSE.txt and add "you agree to pay 50% of your income and your firstborn child"... I don't think many would catch that.
We say "this code is under this license", but actually beneath the hood this means "this code is available for license under these terms".
(In Germany at least the hurdle to enter a contract is rather high. For a time, you were able to get on a bus without paying, and if caught argue that you never agreed to the terms of the bus company... so they had to make a special law against fraudently leeching services.)
Upvoted because this is accurate, but it should be mentioned that "bad" means "bad for Apple", not "objectively morally bad". In particular, it's pretty easy to design an iOS-like security model which doesn't give you GPLv3 problems -- e.g., when you factory-reset the device, if a certain button is being held down, generate a new keypair and display the private key. If you don't actually write it down, nothing stores the private key, and your security model stays entirely intact. And because you can only do it on factory reset, it also ensures that you can't get a signing key that gives you access to any existing user data on the device, while allowing people to resell their iPhones and still comply with GPLv3.
There are some complexities here (and for Apple's goals with iOS, I totally understand them not wanting to work through those complexities), but for a team that has built the most secure general-purpose computing platform in the world, this isn't an unsolvable problem.
It's worth pointing out that this solution neuters Activation Lock, because the thief can now put the phone into DFU, then factory reset it, and then use the new private key to disable Activation Lock.
Compared to destroying the security model of iOS in general this is pretty tame, but it is still a non-trivial downside.
Huh, good point, I didn't know about Activation Lock.
I think this design still works if you only allow generating a signing keypair if Activation Lock is disabled? I think that still satisfies the requirements of GPLv3 sect. 6, although we're probably in territory extremely far from settled caselaw.
> “Installation Information” for a User Product means any methods, procedures, authorization keys, or other information required to install and execute modified versions of a covered work in that User Product from a modified version of its Corresponding Source. The information must suffice to ensure that the continued functioning of the modified object code is in no case prevented or interfered with solely because modification has been made.
The "method"/"procedure" is signing out of iCloud, doing a factory reset, and holding down the button. It doesn't interfere with the continued functioning of the modified object code, i.e., of the OS itself, just with any user data present before you started the procedure.
Would this require end users to factory reset their phone when they buy it (or trust the distribution channel) to ensure that they're not receiving a rooted device?
(Sorry if this question is really misguided, I'm not super familiar with the area).
Yes. However, the seller wants to factory reset it anyway to avoid leaking data, and the buyer wants to factory reset it anyway to ensure the device isn't e.g. saving iCloud backups to the previous owner's account, or doesn't have some weird malware installed (iOS is pretty good at isolating apps, but not perfect, and also jailbreaks exist). So it makes it more important to wipe the device, because attacks are easier, but it's not introducing a fundamentally new requirement.
> According to that, if Apple accidentally ships any GPLv3 on iOS then they'll have to release their root signing keys to the world, which would be disastrous (it would destroy the security model of the OS).
Were I an iOS device owner, I would want the ability to replace the root signing keys on any device I'd own. It'd be my device: why should Apple have the unique privilege of determining what software may run on it?
Apple wants to protect you from attackers, who may have physical access to your device, who want to install a rootkit on your phone.
It's fair to say that the GPLv3, which predates the iPhone, did not anticipate the nuances of people storing all their secrets on a tiny little computer that they keep with them at all times, including when they pass through international borders.
Even so, GP's assertion stands up: being released on the same day, GPLv3 certainly wasn't written with the knowledge of how personal our phones would become.
The GPL is written with the idea that being able to write and modify software on your own devices is good; our devices becoming more personal only makes GPLv3's additions more critical.
(As others have said, there's ways to make GPLv3 work with the iphone's security model, mainly along the lines of requiring a factory reset whenever you want to add an allowed signing key to the device.)
> Apple wants to protect you from attackers, who may have physical access to your device, who want to install a rootkit on your phone.
How does the ability to wipe the phone (and thus the data, and the code compiled and signed by Apple) and replace its signing keys with your own allow an attacker to surreptitiously install a rootkit?
The dangers of physical access to one's devices existed before mobile computing, let alone before GPLv3 or the iPhone.
Don't allow bootloader modifications. Keep the bootloader dumb, with the singular purpose of booting the OS from images verified using user-configurable keys.
This problem has been solved outside of Apple's garden.
Apple needs to solve it in Apple's garden, which runs by different rules.
Unlike other mobile operating systems, iOS prioritizes protecting the user's privacy. The real user, not just any household member or employer who might have physical access to the device.
In your described solution, what prevents an abusive/sneaky household member from posing as the user and supplying those "user-configurable" keys without the knowledge of the real user? Nothing? That answer wouldn't be good enough for the Apple "garden" as you call it.
If a sneaky household member went and wiped the phone to install those new keys, would the real user not notice that all their data is gone?
The function "replace keys" can have any other programmable feature attached to it. Wiping out all preexisting data, reseting the phone to factory settings, and sending a message to the original owner is all possible and would make any sneaky behavior very un-sneaky. They could even require some form of 2auth or other technique that people use to authorize themselves to banks in order to get the unit-unique key to make the TPM memory rewritable. GPLv3 don't require that installing new keys are easy, but the real owner must have a method to do it.
Complexity begets attacks. Apple's policy is "no rootkits". Allowing the user to modify the system software is basically a backdoor, and backdoors have an undeniable history of being abused by people other than their intended users.
Apple sees the iPhone as a hardware security device. Apple wants users to be confident enough in its security that they can use their phones to authenticate financial transactions.
It's great that some phones are modifyable by their users, but I would never ever link my Android phone with my bank account.
Apple has a rootkit. It is called Apple. If you link your Iphone with your bank, you trust that the Apple won't abuse their position that they hold over you.
Personally I prefer that my hardware security device are controlled and owned by me, not the company that sold the device. Devices not owned by me have an undeniable history of being abused by people who sell such devices, like the case of Lenovo.
If you want to use the history of open devices which their owners can own and control as a case against it, the opposite of company approved software has also a history of abuse. How are all those nice lock down car computers that have been acting creatively during emissions tests. How much trust have they earned, and should people trust them with their bank account for say automatic payment at gas stations?
>Were I an iOS device owner, I would want the ability to replace the root signing keys on any device I'd own. It'd be my device: why should Apple have the unique privilege of determining what software may run on it?
Because that's not how security works. If you can just add your keys, an attacker could too...
That's just not true. A secure enclave could, for example, wipe old keys when adding new keys; a physical attacker might succeed in adding his new key, but my data would be secure. That data could include whatever mechanism the phone uses to authenticate itself to me.
I don't trust Apple to be good from now until I replace my phone. I don't trust Google to be good from now until I replace my phone. It's my phone, not Apple's and not Google's.
If a thief breaks in to a home by breaking the door, the broken door is still evidence of a break-in. Let the addition of keys have a noticeable effect. For example, some Android bootloaders show a 'Bootloader Is Unlocked' screen during boot, and almost every Android bootloader wipes the device when the bootloader is unlocked.
>If a thief breaks in to a home by breaking the door, the broken door is still evidence of a break-in. Let the addition of keys have a noticeable effect
Err, security is about preventing attacks -- not about having evidence that they've happened.
By preventing attacks I meant preventing them from being successful -- not preemptively preventing them from happening.
Besides, select "foil", right click "Look up": (OS X Dictionary): prevent
So, not a native speaker, and there might still be some nuance of preventing from even being considered (avert?) in "foil", and you could be technically correct.
I meant the difference between protecting your data from destruction and securing your data against exfiltration.
The former is trivially defeated (just breaking the phone, for example, is much quicker and less involved than forcing a factory reset), and not what we were talking about.
So, with your approach to device security, let's go with the device gets wiped upon the addition of keys.
Then the attacker installs some apps including some special ones designed to spy on the user.
Then they remove the screen lock, or set the password to something guessable or that turns up as a suggestion when Googling for "I can't get into my phone" and return the device to where the user had it last.
The naive user finds their device, gets in, and notices their data is gone. This is real harm.
Now they start using the device, and they are spied on, on an ongoing basis. This is more harm.
I'd have to say your system as described isn't working.
> and notices their data is gone. This is real harm.
That's only slightly better than losing the phone itself.
> Now they start using the device, and they are spied on, on an ongoing basis. This is more harm.
This is more substantial. But if you are talking of the naive user who would not take notice of their Apple account suddenly vanishing from their device, there are easier ways for breaking in to their device without having to wipe it.
Apple's system doesn't work to secure naive users against dedicated attackers. If Apple's system has any design for security (and I agree it does), it's for users who'd notice when their data is wiped.
Your comment is a mixed bag. Have you owned an iPhone lately? It does work in a lot of ways.
When you say it doesn't work against dedicated attackers, maybe you are thinking of an iPhone 6 hacked by an Israeli security company paid by the FBI? For one thing, most people don't have the resources of the FBI. And I think Apple has raised the bar significantly in the three or more generations since that device.
If you were to own an iPhone and also apply some conscious awareness to noticing what it does on your behalf to protect your security, I think you would agree it has a lot of very effective measures to protect users.
No,I'm talking about dedicated attackers of any level against naive, unsuspecting users, as you brought up. The FBI case was against a user who knew the FBI was after their data, thus not unsuspecting.
Social engineering, for one, is much easier against naive unsuspecting users than wiping their phone and hoping they wouldn't bother.
For those who truly care about their own data security though, a wiped phone is an instant siren.
----
I have used an iPhone, though only for a short while, and not long enough to get used to it. I agree it goes a great, great distance to protect users against everyone not blessed by Apple.
But then I have greater data security on my laptop and far greater freedom too, so Apple's offering doesn't seem like a good enough deal to me.
With mobile there are some constraints that are not a factor on a laptop. For example you don't have a full sized hardware keyboard. Which seems obvious, yet you are expecting a better deal than what you perceive Apple is offering. And you are making the unfair comparison to a laptop.
Also with a laptop the use cases generally can tolerate a bit more delay in the login process, with a few seconds being tolerable, whereas with mobile devices a login process over a second starts to get intolerable very quickly as the length of the process increases. Again this may be obvious and yet you seem oblivious to it as a consideration, as you expect a better offer, as though there are no constraints and tradeoffs, or you are unaware of them.
Mobile device designers and mobile system designers deal with this stuff every day for years on end. They know a lot about it, and have thought stuff through way more than some of us. It's super easy for you to criticize from a position of relative ignorance (not even a current iOS user...) but I'm pretty sure they are still following the mantra of trying to make stuff insanely great.
Still, you can dream of even better devices. I'm sure the bar will keep being raised. Let's hope we get there to a place where we do have both freedom and security.
I'm aware of the constraints being different on a mobile vs. a laptop. But that is no reason to pivot your arguments from "But Apple gives you so much security it's okay for you to give up freedom" to "But it's a mobile; Apple can't give you that much security; you'll just have to deal with it".
> Again this may be obvious and yet you seem oblivious to it as a consideration, as you expect a better offer, as though there are no constraints and tradeoffs, or you are unaware of them.
I'm not oblivious to the tradeoffs of security. I know that if I set a long password it only makes every login that much more tedious. And that's my problem to deal with. But to have no choice, no freedom, no chance of owing your device, in the name of "security", is either unmindful or wilfully ignorant of a manufacturer.
----
You keep saying I'm not a current iOS user so I couldn't possibly see the great things iOS does. I merely doubt it could do anything beyond generally security focused OSes. For example, my current mobile OS has a separate decryption password at boot, scrambles the lock screen numeric layout, compartmentalizes my data, hooks into every way apps can request private data and lets me allow/disallow/fake it, hooks into every way apps can even run and lets me choose which to allow/disallow, and still provides me the freedom to run whatever I want and share whatever data I want with whichever app I want.
I'm not dreaming of much more, largely because I already have quite a lot.
Another way to comply with the license is to remove the accidently shipped GPLv3 software. No need to release source code or keys if you don't want to.
Nope, GPLv3 doesn't break any security model other than security by obscurity.
Android could very well use GPLv3 and have no consequence on its security model.
As long as the bootloader is open-able, the Tivo-ization rule of GPLv3 is respected.
If Apple uses GPLv3, it will piss them off quite a lot, but it won't impact their security at all.
Of course it will. The iOS security model fundamentally depends on everything from the bootloader up being codesigned. Releasing the root signing keys completely destroys this. Nothing on the system can be trusted anymore if that happens.
Edit: Well, I guess the secure enclave can be trusted. But nothing else can be.
IANAL, but if they had a way for a legit owner of the device (for some definition of being able to prove that) to use their own keys in addition to the apple ones then no security is compromised and gpl3 is satisfied.
It bothers me that you are confusing Apple's policy choices, which are not inevitabilities nor are they without dissenting opinions, with security, suggesting there is no possibility to satisfy the latter without making the same choices as the former.
It can still require signed code. I just want to swap Apple's key for mine. As the owner of the device, by definition, I am the sole arbiter on what is considered trustworthy. Executing only programs that I have personally approved (and thus carry my signature) is the perfect implementation of that policy.
Now, I might be lazy or busy and delegate that responsibility to Apple or some other third party. There may be mismatches between my preferred policy and what is enforced by my proxy, but it might still work reasonably well overall. We humans do it all the time. No reason the CEO has to make every single decision themselves.
When the stakes are high and I don't want to risk that nuances of my set policy get lost in translation or when it's about things that are totally outside my proxy's area of expertise, I'd prefer to make the decision myself.
With iDevices, I can't. There's only the delegate model and the only available proxy to choose from is Apple.
PS: Releasing secret signing keys to the whole world is an obviously bogus suggestion. Please stop beating up this strawman.
It's not a strawman. It's what would have to happen according to the GPLv3. The fact that you could design a system that allows for user-replaceable keys doesn't change the fact that iOS is not that system, and that if GPLv3 code gets into iOS then, according to the terms of that license, owners of existing devices would need to be allowed to replace the code. And the only way to do that is to release the root signing keys. You can't say "well they could design a future device to allow this", because that hypothetical future device isn't what we have today.
It's a bit more complicated, since you don't want a third party (e.g., your local police or your abusive ex) to be able to open your bootloader and run a modified OS that dumps your private data the next time you log in. This is completely straightforward on a modern desktop (unless you're using something like Bitlocker with TPM), but is supposed to be impossible on iOS.
There's too much cargo cult information getting repeated in this thread and going unquestioned. Apple doesn't care about the patent grant parts of GPLv3. The Apple Public Source License was an early pioneer in granting patent rights. Most modern commentary FOSS licenses are modeled after the grant from the APSL, starting with Apache 2.0, and including MPL2 and GPLv3. There's nothing in the GPLv3 for Apple to quibble about wrt patents; it has everything to do with the GPL's Tivoization stance.
Much of the kernel (XNU), forks of BSD utilities, WebKit, LLVM/Clang, and various other projects are hosted there. This site predates GitHub, but folks have mirrors hosted there of most projects. Apple’s newer open source projects (Swift, ResearchKit, etc) are on GitHub.
You had many questions, but source code doesn't need to be on Github to be open source, especially when it's being maintained and developed purely by people hired on the core os team inside apple.
You could ask why it's not on a private github repo, and the answer is that Apple's code predates Github by probably up to a decade, and depending on workflow and privacy reasons being on github is probably useless and/or veto'ed by their legal department.
There are so many ways to work on open source. Github is just one tool.
Just to note that Swift is on GitHub[0] and has a very inclusive community.
The impression I get is that Apple isn't really interested in soliciting outside contributions for their OS/kernel code, which is why they're just code dumps.
Some of their stuff is on Github, but must of their stuff is on the linked website. The stuff that is open sourced here is mainly stuff like the Mach kernel, the BSD base system utilities, etc. For the most part, I didn't find the stuff here very useful, with the exception of an issue with 802.11x back in OS X 10.5 days. Was nice being able to reference the exact line in the code in the Radar I filed that was causing the issue.
Having it hosted on some kind of revision control system would be very useful and GitHub is the most prominent public place to do that, but otherwise no real reason.
Apple is a big fan of GitHub, you can see evidence of that with the Swift project (https://github.com/apple/swift), but not everything is suitable for that sort of treatment.
It could be workflow related. The OS team has been around for decades and pivoting to a new RCS for a whole OS is not easy.
Over last 10 or so years there were various conflicts between open source projects and Apple that were caused by absence of publicly accessible version history for open source code shipped by Apple as part of OS X. Probably most significant such conflict was around KHTML/WebKit (and I somewhat believe that Chrome was at least partially Google's reaction to that)
Google forked WebKit and called it Blink, which Chrome uses. It might be partly this but I guess also that Google prioritized implementing a multi-process architecture.
As I understand, the fork was more about architectural disagreements between Google and the WebKit team. For instance, in Chrome the multiprocess system is part of Chrome whereas WebKit does multiprocess within WebKit itself. This means that anything embedding WebKit2 automatically gets multiprocess, where to get the same with Blink you've gotta fork Chromium.
Now that I think of it, Google seems to take this approach with a lot of features. I guess that's why everything based on Blink forks or embeds Chromium instead of using bare Blink.
- My understanding is that the Blink fork happened because Google was the primary contributor to WebKit prior to the fork, and Google engineers were spending a significant amount of time trying to make Apple engineers happy. Additionally, there was a lot of code needed to support both Apple's and Google's JavaScript engines and multi-process implementations, which was no longer needed after the fork. WebKit2 and the Chromium multi-process architecture did exist for some time before the fork.
- WebKit2 is a layer on top of WebCore, which is the part Blink forked. So both WebKit and Chrome implement multi-process in another layer on top of the renderer. I'm not familiar with WebKit2, but in Chrome, this is done in the content layer, which provides most of the core rendering code (including the multi-process stuff), but without all the browser-specific features (e.g. autofill, extensions, spell check, etc.). I believe Opera is currently built on top of the Chromium content layer.
This is more or less my memory of the fork. Google were a major contributor, wanted to make some different decisions in various places to Apple and spent lots of time trying to make Apple happy, and concluded the quickest way to make progress was to fork and not have to convince other contributors (even with the resultant loss of contributions from others).
Opera is indeed built on the Chromium content API (v. the Chromium Embedded Framework, which provides a stable API but was less power), and that was a design choice made prior to the Blink fork and hence why Opera followed Google to Blink.
That depends. You don’t have any helpful commit logs or even changelogs. But if you arrange e.g. the XNU releases in the form of a reasonable graph and import them into git that way, you can get some telling diffs, on the command line at least. GitHub is not being very helpful here because it does not allow you to diff arbitrary tags and revisions from a repository. But GitHub is still a place where people find and look for code.
As long as my memory is still working, the closed parts were mostly the GUI (Aqua), the network stack, and (of course) all the utilities like mail client, iTunes, etc.
The initial board perspective is similar, but otherwise, the two apps are quite different (One obvious difference is that NeXTStep Chess.app used a bitmapped board with a fixed perspective).
What do we have to do to get Apple to actually update OpenSSL? It's beyond ridiculous. They're shipping the OS with a version of OpenSSL that is completely unsupported, and doesn't support newer security features.
Apple announced many years ago now that they were not going to update the version of OpenSSL, and that the reason they were not going to do that was because of binary (and source) incompatibilities that OpenSSL routinely causes in major updates.
This is very old news, and has been hashed out many times. The thing I don't understand is why no-one has created a shim on top of Apple's SecurityFramework to mimic OpenSSL, so things could be compiled against it. While it would be near-impossible to do this for all of OpenSSL's many features/modes (most people hate this), my bet is that it would not take much to completely cover what 90+% of projects need.
Because they patched it and they don't use it themselves, it's only for backwards compatibility. On top of that, it is not 'supported' by Apple, all programs for macOS use Objective-C and Swift libraries that abstract crypto to the point where it doesn't matter if under water some OpenSSL/LibreSSl/BoringSSL call is made.
A little disappointed to see that they're still shipping Ruby 2.0; a version shipped 4 years ago. I would hope that they would update this soon to keep up to date with the language and security patches
Never expect Apple to ship anything recent. Anything outside of their own "core system" that depends on 3rd party packages is likely to be 2, 3, 8 years out of date. Software like brew and macports aren't only popular for "extra" software; they're popular for replacing bundled software that is severely out-of-date. Last time I started from scratch, that included updating git and php from versions so old that it was laughable. Let us be thankful that these alternatives exist.
Just to be clear, though, this isn't because Apple isn't interested in updating things. It's specifically because much of that software moved to GPLv3, and Apple won't include any software with that license. (The internal documentation is very clear about that haha.)
It's the Tivoization clause of course. Darwin is the basis for not only macOS but also iOS, and Apple doesn't want to provide support for replacing the software on iOS devices.
If I recall right it was the patent agreement clause, where they would have to transfer any patent rights from negotiations with partners that in theory could cover the GPLv3 work.
So if Apple has a deal with a patent troll which has a an obvious broken patent that covers all and every program (but which would fall apart if challenged), then apple could in theory get into trouble with the troll if they distributed GPLv3 software.
Don't do shady deals with trolls then? Or, if that's not possible, at least do them in a way that grants downstream recipients of your software the same patent rights that you got from the deal.
There is precedent for the latter. When Red Hat paid off the Firestar troll, it negotiated a patent license for all recipients of the software, including upstream and derivative versions.
Discouraging individual patent deals with a troll while leaving the rest of the community (from whose software you benefit) vulnerable doesn't seem like a bad thing to me.
fish has been GPLv2 since well before ridiculousfish took over as the maintainer; changing to GPLv3 is not something we have the appetite or energy for!
Ahh right, tcsh! Thanks for reminding me. I think being so lost at the tcsh prompt is what first prompted me to start learning other shells and ended up with Zsh for a long awhile.
Also, I had no idea the fish dev worked at Apple. I have no hopes of them going with that as a default, but I could certainly see them shipping it as part of the os...
fish should be the default shell on macOS, possibly with a cool custom theme. then again it might turn off some of the hardcore bearded UNIX people who use it.
On second thought this might lose them SUS certification so perhaps they shouldn't do this. I just think macOS is a friendly OS and fish is a lot friendlier than bash or even zsh out of the box (it's even right there in the name!).
Edit: to clarify, any shell script that is executed will define its own shell to execute with (the #! line).
There may be some issues if scripts have declared their shell as /bin/sh but they use bashisms, and then /bin/sh isn't provided by bash anymore, but honestly that's not necessarily related.
The discussion here is about changing the default login shell for interactive user accounts to fish.
If they did this though, it would be nice if they would use dash for /bin/sh, but I'm not sure how that's licenced - possibly gpl3 too?
What I would like to see is for them to ditch all the GNU/GPL stuff and go with BSD for userland. Shipping old stuff is unacceptable and it's not like we can't install it if we want it.
> What I would like to see is for them to ditch all the GNU/GPL stuff and go with BSD for userland.
That sounds like an odd thing to wish for in software where you are the user. That's asking for less freedom.
So why would you do that?
> Shipping old stuff is unacceptable and it's not like we can't install it if we want it.
I can't see how 1. this is related and 2. how Apple would bother putting in the effort to replacing its full toolchain with completely different implementations when they can't even bother updating the one they already have.
Basically... This is all on Apple's hand.
But if you want a modern, updated toolset which you know will be kept up to date, I know there are lots of Linux distros out there which can deliver what Apple seemingly can not.
"That's objectively false. GPL provides more end-user freedom. BSD provides more developer freedom. There's not a single license which objectively and universally offers more freedom."
I disagree. Forcing people to do things is not "more freedom", although the GPL's goals are laudable.
"False dichtohomy. That's comparing rotten apples to ripe oranges.
You either have to compare old GPL to old BSD or new GPL to new BSD.
And as an end-user I would prefer both new and GPL."
Unfortunately, new and GPL is not an option. But this result is what the FSF wanted when they created the GPL3.
At this point it could well be about keeping backwards compatibility. There are some obscure cases where the bash on mac behaves differently to a modern one. And there are going to be scripts relying on it.
Personally, this is why I would prefer that UNIX vendors/distributions not include advanced languages like Python, Perl, Lua, and Ruby. It seems like it ends up causing more issues than it solves.
I remember when Darwin was binary ISOs, and then it just became source code and you had to hunt all over the Internet for ISOs as Apple didn't make them anymore and then anyone that did you suspect of putting a trojan in the binary.
I assume this MacOS Source is the parts of MacOS that go back into BSD Unix that Apple promises to share with the free and open source communities?
Anyone tried compiling the source code yet to see if it works and can be made into a binary ISO file?
This makes it a bit harder to use or test darwin because you have to set up your whole build toolchain... it might be to make creating hackintosh patches harder, but I imagine it was just a standard corporate situation where the resources required to keep churning out these builds was higher than the demand for them.
I don't think that would work; Darwin includes the XNU kernel, so it wouldn't make sense to run it in Docker, which is containers under a Linux kernel. A VM is the right solution here.
Very little of the components of macOS are open source, except for XNU kernel, WebKit, and compiler. You’d have a hard time taking what’s on opensource.apple.com and making an OS.
You can already do that via cross compiling with osxcross[0], but you need the native SDK (you can copy it from any Mac). I have used it at the past as a part of a (Linux hosted) build process to create OSX binaries for some (GUI) stuff i was working on (the same process created Linux and Win32 binaries too).
Thank you very much for information. I'll look into it since Travis Mac builds sometimes so annoyingly slow so for majority of builds we can just use cross compiler.
