MacOS 10.12.6 Source

Re:MacOS 10.12.6 Source by geofft on Thursday September 14, 2017 @05:35PM (#15252709)

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.

[ Parent | on HN ]

Re:MacOS 10.12.6 Source by eridius on Thursday September 14, 2017 @05:40PM (#15252748)

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.

[ Parent | on HN ]

Re:MacOS 10.12.6 Source by geofft on Thursday September 14, 2017 @05:45PM (#15252782)

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.

[ Parent | on HN ]

Re:MacOS 10.12.6 Source by baybal2 on Thursday September 14, 2017 @06:16PM (#15252943)

It didn't prevent Chinese refurbishers from working around it in the most simple way http://www.zdnet.com/article/iphone-lock-did-hackers-drive-a...

[ Parent | on HN ]

Re:MacOS 10.12.6 Source by hyperpape on Thursday September 14, 2017 @10:51PM (#15254199)

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).

[ Parent | on HN ]

Re:MacOS 10.12.6 Source by geofft on Thursday September 14, 2017 @11:36PM (#15254423)

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.

[ Parent | on HN ]