Apple – The Wacky World of Chris Knight

2022/08/272022/08/27

Squeezing more life out of Apple hardware

Planned obsolescence is theft. That’s the perfect distillation of my feelings on the topic. If I spend my hard earned money on a product I don’t think the manufacturer gets to tell me when I have to stop using it. And yet, there are countless cases of this:

Don’t get me wrong, I’m not some crazy person who thinks Apple should still be selling parts for the Apple II+ my uncle has in his attic. There does need to be a line drawn somewhere; just don’t ask me where.

Ask yourself this: If you just spent $5,999.00 USD for a MacPro (that’s the base model, with no upgrades), would you feel a bit ripped off in seven years when Apple won’t even sell you replacement parts?

What if you were really crazy and bought a full decked-out Mac Pro for a whopping $54,384 USD? Yeah, well, Apple is still going to cut off your support in seven years.

The thing is, everything Apple sells with a Pro moniker comes with a premium price, and it doesn’t seem too outlandish to expect them to support these products for a reasonable amount of time. What makes for a reasonable amount of time? I’d say that if a bunch of hobbyists on the internet can support a product, then one of the world’s most valuable companies can probably manage it as well.

For instance, I have a Mid-2010 Mac Pro (MacPro5,1). The last supported OS for this model was Mojave, but some of the nifty features like Handoff were expected to be broken since Yosemite due to the Bluetooth module used in this model. Apple would have you believe that the Bluetooth incompatibility was un-fixable, and that no OS past Mojave will work on this model. And yet… via a series of upgrades over the years, I’ve got this twelve year old machine running Monterey just fine, and even Handoff works. So much for impossible.

I owe a lot of my machine’s lifetime to the folks at macvidcards.com, who have been providing custom flashed video cards, and other bits, for years. While you technically don’t need a Mac EFI driver flashed video card to run most versions of MacOS, you do need it if you encrypt your boot drive with FileVault or you won’t get the screen to unlock the drive’s encryption. For a security wonk such as myself, full disk encryption is absolutely necessary. So far, I’ve installed the following upgrades:

Nvidia GTX 680 (pre-Mojave)
Nvidia GTX 980 Ti (pre-Mojave)
Wifi AC and Bluetooth Airport Card (works with Handoff and other BT 4.0 features)
Apple EFI AMD RX580 8GB Sapphire Nitro (AMD needed for Mojave and later)
Sonnet Allegro USB 3.0 PCIe 4-Port
Samsung SSD 870 EVO 4TB

So, all of that got me up to Mojave. I did have some fun little issues, like MacOS claiming that FileVault was not supported on my Mac Pro and refusing to encrypt my drive after installing Mojave. I solved that by moving my SSD to an external enclosure, booting my laptop on it, and enabling FileFault. Funny, my Mac Pro booted from that FileVault drive just fine, and hasn’t had a problem since.

My adventures have not been without pitfalls, though. The roughest being when I installed Big Sur, because that point I had to give up using VMWare Desktop. The version of VMWare Desktop I ran under Mojave wouldn’t run on Big Sur, and pointed me to a newer version. That newer version would not run on my hardware because my installed CPUs lacked a particular instruction set. This was a bit of a blow, particularly because when I tried Parallels Desktop it would seem to import my VMWare systems, but then they wouldn’t boot. So far, there doesn’t seem to be a way around this. If you’ve got any suggestions, please comment below!

Up until this point, I thought Big Sur was as far as I’d be able to take it. Shoehorning Big Sur on had taken experimenting with a few different EFI bundles, from several forum and blog posts, where the takeaway was that Monterey was too problematic. But then… I saw this slashdot post: Devs Make Progress Getting MacOS Venture Running On Unsupported, Decade-Old Macs

I was aware of OpenCore, but I couldn’t recall if I’d come across the OpenCore Legacy Patcher. Reading through the docs, it looked pretty simple. Could it really be this easy? I deviced to give it a try and dropped a spare SSD into my machine. I’m not going to detail the steps I had to go through, as they are all very well documented here, but I will say that an hour later I had a functional Monterey installation on my Mac Pro complete with hardware graphics acceleration for HVEC and h.264 encoding!

OpenCore Legacy Patcher is proof that my twelve year old Mac Pro is capable of running modern MacOS, and that Apple’s planned obsolescence is not a technology issue.

2015/09/142017/09/15

Installing MacPorts on OS X 10.11 ‘El Capitan’

High Sierra Update: If you are looking for instructions on how to manually install MacPorts onto the High Sierra GM release, check here: Installing MacPorts on MacOS “High Sierra”

Update: MacPorts has released their official El Capitan installer. You should probably use it instead. 🙂

Update: Since people are ignoring my above comment, I have updated the below instructions to reflect the version changes reported by Chrisp in the comments.

Another year, another OS X update. If you are like me, you’ve weaseled a copy of the OS X 10.11 ‘El Capitan’ Gold Master installer, and you have started checking to see how much of your software is going to break if and when you install. Given the issues I’ve had in the past, MacPorts is the very first thing I test. 🙂

The first thing I noticed is that there is no El Capitan installer for MacPorts, and the Yosemite installer will not run on OS X 10.11. So, we are back to compiling it ourselves. Fortunately, this goes pretty smoothly.

The first caveat is that in addition to needing access to OS X 10.11 ‘El Capitan’ , you will need a copy of Xcode 7 (beta, RC, etc). You won’t be able to compile MacPorts for El Capitan with Xcode 6 because of changes to one or more of the header files that ship with the OS X 10.11.

The second caveat is that I did a clean install of OS X 10.11 ‘El Capitan’, so my instructions may not adequately deal with any cruft left over by previous installs. If you have an upgrade issue, please comment here and I’ll do my best to help you out and improve the instructions. You may want to follow the MacPorts uninstall instructions before starting the below steps.

Install OS X 10.11 ‘El Capitan’
Install Xcode 7
Launch Xcode:
1. Agree to the license.
2. Let it install the extra components it says it needs.
3. Quit xcode.

Open a terminal window:

```
sudo bash
```

export PATH=/usr/bin:/bin:/usr/sbin:/sbin:/usr/local/bin

```
xcode-select --install
```
```
cd Desktop
```
```
mkdir macports
```
```
cd macports
```

curl -O https://distfiles.macports.org/MacPorts/MacPorts-2.3.4.tar.gz

```
tar xzvf MacPorts-2.3.4.tar.gz
```
```
cd MacPorts-2.3.4
```
```
./configure --enable-readline
```
```
make && make install
```

echo 'export PATH=/opt/local/bin:/opt/local/sbin:$PATH' >> ~/.profile

```
source ~/.profile
```
```
port -v selfupdate
```

At this point, you should be ready to start reinstalling your ports! Wee!

If you see this error at step 4-10:

checking for Apple Foundation library... no
configure: WARNING: GNUSTEP_SYSTEM_ROOT is not defined in your environment, preventing the use of GNUstep's Foundation library
configure: error: Could not find a working Foundation implementation

It means you either have not installed Xcode 7 GM, or that you are running Xcode 7 Beta. Xcode 6 doesn’t know how to handle the changes to /System/Library/Frameworks/Foundation.framework/Headers/Foundation.h that happened with El Capitan. The configure script is able to find the header file, but the test compile fails so it reports that the Apple Foundation library isn’t there.

If you are running Xcode Beta, you can get around this by using the following command in the shell you opened above, and then going back to step 4-10: (Thank you SadDigger for the comment on Reddit!)

xcode-select -s /Applications/Xcode-beta.app

Update 2015-09-15 11:06AM – Fixed a typo in instruction 4-3 where WordPress was converting a double-hyphen into an extended hyphen. I have also updated it to the latest version of MacPorts, so that the final just updates the ports rather than rebuilding the whole thing. Sorry about that!

2014/05/252014/05/28

The Importance of Monitoring SSL Certs

The certificate for this server is invalid. You might be connecting to a server that is pretending to be “swscan.apple.com” which could put your confidential information at risk.

As of 4:59 PM on 5/24/14, every Apple user is getting the same scary error.

Don’t worry, you are probably not the victim of a man in the middle attack. It appears that the SSL cert for swscan.update.com, which is hosted at Akamai, has expired. This was probably due to a gap in the monitoring and management of the SSL certs provided to Akamai.

It is certainly possible that Akamai has been hacked, and a compromised SSL cert was installed. Not likely, though. To be safe, just hold off on any updates until Apple and Akamai get the cert updated. Alternatively, you can download updates directly instead of using the App Store. You can download all major updates here, and this server uses a different SSL endpoint that has a valid certificate: http://support.apple.com/downloads/

Pro tip for Apple’s security team: Even though swscan.apple.com lives at Akamai, you should set up SSL cert checks in Nagios for all exposed HTTPS end-points that are in the apple.com domain. These are the sorts of things you want to get notified about 60 days in advance. In the unlikely event that Akamai has been hacked and the cert replaced, this type of monitoring would have immediately alerted you. Win-win.

Both Apple and Akamai should have been monitoring this SSL cert. I do not think anyone should lose their job over this. If anyone does lose their job over this, that would be a failure of management, not the person or team responsible for SSL certs. I think this should be seen as an opportunity for improving monitoring and business processes.

I tried sending an email to security@apple.com to let them know they had a critical SSL cert that has expired. My email received an error in response: “Your message to jmet-si@group.apple.com could not be delivered for the following reason: This group does not accept external messages.”

Update: I received a response from Apple’s Security Team. They obviously resolved the expired SSL certificate, and they’ve addressed the bounce issue I reported. Fairly promptly, for a holiday weekend.