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?

Bare bones Mac Pro, 2022-08-28

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.

Maxed out Mac Pro, 2022-08-28

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:

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.

Never Give Someone Your Secret Keys

You didn’t need me to tell you that, though. Right? It goes without saying, as it’s right in the name. Secret Key. You give people the other half, the Public Key. I think they teach that in kindergarten these days.

So, why am writing a post about such a simple topic? Let me tell you a story…

I’ve been using keybase.io for years.

I probably haven’t been using all its features, but it serves as another way of verifying some ways of communicating securely with me.

keybase.io was bought by Zoom, and we don’t know what that means yet. Will it stay free? Will it get shut down because all Zoom cared about was the crypto skills and tech?

One thing that is happening is that at least one ‘competitor’ has already popped up. Yesterday I received an invite from Cyph to sign up. They’d conveniently scraped my public info at keybase.io and populated an account that was ready for me if I accepted the invite. All I had to do was click the link and provide a new password and PIN. What the heck, I’ll sign up and make sure I get the name Ghostwheel before Scott in Atlanta grabs it.

There’s a reason I put ‘competitor’ in quotes is because there is something very phishy about Cyph. The website at cyph.app wants me to prove I own the pgp public key they scraped from keybase.io by… uploading my private key to their servers.

That. is. not. going. to. happen.

That’s now how it works. That’s not how any of this works!

You want me to prove I own the secret key? Give me a random blob of text to sign, and you verify it with my public key.

You want to compromise any pgp/gnupg encrypted communications I have ever had? Yeah, that’s when you ask for my secret key.

Now that I’m taking another look at the invitation email, it isn’t even properly signed. It has a signed.asc but it’s malformed. Looking more phishy by the minute.

We’re supposed to move from keybase.io to a website that wants us to add our secret keys to their keystore, and where the CEO can’t send a properly pgp signed email?

Yeah, nah.

Nebula: The Zero Trust Networking Tool You Didn’t Know You Needed

I first became aware of Nebula a few days ago, thanks to two excellent write-ups at Ars Technica. (here and here) It’s an open source product freely given to the world by the folks at Slack. (Best known for making billions putting a fresh skin on IRC.). While those two write-ups at Ars Technica do a decent job at introducing Nebula, I feel like a use case for Nebula that hasn’t been fully explained.

Nebula isn’t like the VPNs for which you are constantly bombarded with ads. It isn’t designed for you to hide your torrent traffic, or to mask your IP address. It is designed to secure communications between systems you control, and makes for an excellent building block in a Zero Trust implementation.

First off, what’s “Zero Trust”? It’s the idea that you can’t trust any of your infrastructure, any more than you could trust the Internet. It’s logical evolution of the old adage “never trust the client”. If you can’t trust the client, you can’t trust the network they are connected to either. Assume at all times:

  • There’s a compromised device on your network sniffing traffic.
  • All of those ‘Smart Appliances’ you got for Christmas are remotely hackable, if they weren’t flat out designed to attack your network from the inside.
  • Any machine can have zero-day malware that isn’t detectable yet.
  • The NSA has a tap on your AWS VPC (Virtual Private Cloud).
  • Any of the Five Eyes countries have taps on the switches/routers at your ISP.
  • The ‘free WiFi’ at the cafe is sniffing traffic to insert ads, or worse.
  • Your ISP is sniffing traffic for * reason.
  • Your SuperMicro server has the Magick Chip that sends data to China.
  • Your network gear has Huawei components.
  • One of your sysadmins didn’t get enough of a raise and has sold access to your network for fun and profit.
  • There are a thousand other risk factors not on this list.

The old paradigm was built around a division of realms: the trusted home/office/datacenter network and the wild west of the Internet, with firewalls in between. That paradigm is shifting with the acceptance of the reality that devices inside your trusted network are going to be compromised. By accepting that, and making design decisions with that in mind, the impact of your future compromise(s) just might be reduced.

Now that you are starting to embrace the appropriate level of paranoia, how does Nebula VPN help? Nebula lets you create a mesh VPN between the hosts in your network, whether or not they are on the same subnet or in the same VPC. It allows you to secure traffic that was otherwise difficult to secure, or that you wouldn’t normally consider securing because it takes place in a ‘trusted’ layer of your network. With Nebula it becomes trivial to encrypt MySQL, MongoDB, Redis, Memcache, etc, traffic; restricting access to hosts with the appropriate certificates installed while also limiting exposure if another instance in your infrastructure becomes compromised.

Unlike traditional hub and spoke VPNs, Nebula functions as something closer to a mesh. In a traditional VPN, two clients who want to talk to each other would have to route their traffic to the server and back. With Nebula, clients negotiate the best way to talk to each other, using the shortest route possible. This is a far more efficient use of bandwidth.

I spent a couple of hours adding a new column on my IP/subnet spreadsheet, creating certificates, and writing a Puppet module to deploy Nebula in my quirky infrastructure. I now have a virtual VPN subnet that spans systems across two continents, where I can now use the Nebula IP for a host to automagically encrypt traffic.

I haven’t used Nebula long enough to run into any gotchas, which means I’m still a novice. Despite that, I do feel secure in saying that it makes for a powerful tool in your Security toolbox.

If you want to give it a try, this write-up at Ars Techica will have you up and running in ten minutes or so.