SpinRite is a fantastic tool for repairing and maintaining hard drives, and I am proud to say that its purchase price has been more than recouped on drives that it has brought back into service that would otherwise have needed replacing!

Running it on an Intel Mac hasn’t been possible with version 6.0. It actually boots fine, but there is no way to give keyboard input, and thus there is no way to kick off a scan.

Reports that people had succeeded at getting SpinRite to work on various weird and wonderful platforms indirectly, using VirtualBox and its raw disk access mode, led me to experiment with this to run SpinRite on a Mac. This is particularly useful on iMacs where pulling the hard drive out of the case is… undesirable(!)

Boot from another disk

You’ll need a working MacOS install on another disk that you can boot from, as we need to unmount all the volumes on the disk to be scanned in order to gain raw access to the disk. I use SuperDuper to make bootable backups, and these work great for this purpose too.

Prepare the Environment

Make sure you have VirtualBox installed, with the optional Command Line Tools.

Turn off screen savers, sleep timers and screen lock, just in case the VM has taken keyboard input away from you and you are unable to unlock the Mac to check on SpinRite’s progress. It’s certainly not an ideal situation to have to pull the plug on the computer while that VM has raw access to your target disk!

Identify the Target Disk

It is critical that you identify the BSD device name for the whole disk that you want to operate on. In my case, I’d booted from disk1 and the SpinRite target disk was disk0.

Determine the correct disk identifiers with:

diskutil list

» Read the rest of this post…

Even despite the dominance of webmail, I have long used a traditional desktop email client. I like having a local mail archive should “the cloud” have trouble, as well as the ability to exert control over the user interface and user experience. (That might be partly a euphemism for not having to see ads!)

Apple’s Mail.app built into macOS (going to have to get used to not calling it OS X!) has served me pretty well for quite some time now, alongside Thunderbird when I’m on Linux, and while Mail.app offered the most smooth interface for the platform, it didn’t always have all the features I wanted.

For example, being able to run mail rules is more limited than I wanted in Mail.app. I could have rules run automatically as messages arrived in my inbox, or disable them entirely. But actually how I wanted to use rules was to be able to cast my eye over my inbox, and then bulk archive (to a specific folder) all emails of a certain type if I’d decided none needed my fuller attention.

Recently, I moved to Thunderbird on my Mac for managing email and discovered QuickArchiver.

As well as letting you writing rules yourself, QuickArchiver offers the clever feature of learning which emails go where, and then suggesting the right folder to which that message can be archived with a single click.

It’s still early days, but I am enjoying this. Without spending time writing rules, I’m managing email as before, and QuickArchiver is learning in the background what rules should be offered. The extra column I’ve added to my Inbox is now starting to populate with that one-click link to archive the message to the correct folder!

It’s just a nice little add-on if, like me, you (still??) like to operate in this way with your email.

Today I release DfontSplitter 0.4.2 for Mac. This is a critical security update that fixes an issue relating to the Sparkle software update framework when the update pages are served over HTTP. As of 0.4.2, the update pages are now, naturally, served over HTTPS. (It was more than five years ago when the last release was made!)

The vulnerability means that in a scenario where an attacker could launch a man-in-the-middle attack during a Sparkle-enabled app’s update detection process, arbitrary JavaScript could execute in the WebView hosting the release notes. Due to the context that the WebView runs in, the app could then be convinced to run local files, expose local files to a remote server and even execute arbitrary code. More details and a full breakdown are at the post on Vulnerable Security.

This update fixes the Sparkle-related security issue by updating Sparkle and requiring HTTPS for all future DfontSplitter app update communications. Due to new build requirements in Xcode 7.2, the application now requires at least OS X Snow Leopard (10.6) and a 64-bit Intel processor.

The automatic updates feature within DfontSplitter should detect the update, but you can also download and install it manually.

Thanks to Kevin Chen for pointing out the existence of the issue with Sparkle and that it affected DfontSplitter. I had somehow missed the original reporting of the vulnerability, so I particularly appreciate Kevin bringing this to my timely attention.

The astute among you may note that in the Info.plist for this update, I explicitly disable the OS X 10.11 SDK’s check for HTTPS forward secrecy in the HTTPS communications to the update server. Once I figure out a cipher suite configuration that I am happy with, and understand, in Pound (my reverse proxy acting as the TLS terminus), I will update the app again to require forward secrecy.

SuperDuper is one of my favourite backup applications for the Mac, and I use it as part of my backup and recovery strategy.

One of its benefits is creating a bootable clone, so in the case of any trouble, you can connect the backup drive, hold Option/Alt and boot your alternative system.

The world has changed since I first used this tool, and full-disk encryption is now essential for maintaining privacy and “not-having-your-life-turned-upside-down” in the event of a loss of control of the drive with your life on it. FileVault on OS X since Lion works beautifully for your boot drive, but unfortunately I had to sacrifice the bootability of my SuperDuper backup in order to ensure it was encrypted.

Recently, a drive failure on my SuperDuper backup drive (yep, they do happen, and that’s why we back up!) required me to replace the drive. That gives a good excuse to play, and try and make a bootable and encrypted backup — FileVault-style, but on an external disk that we manage ourselves.

» Read the rest of this post…

Before the release of Apple’s OS X Mountain Lion, when the Gatekeeper feature was first announced, Apple proudly proclaimed on the relevant page that developers distributing their apps outside of the Mac App Store would be able to get a “free Developer ID certificate”.

Unfortunately, I did not have the foresight to screenshot the page that said this, because now, even a month after the release of Mountain Lion, their generosity appears to have evaporated.

Only Mac Developer Program members are eligible to request Developer ID certificates and sign applications or installer packages using them.

The aforementioned Developer Program(me) is the standard, $99/£69 per year subscription that entitles you to full Mac App Store distribution rights. Unless I am missing something obvious, and I really wish that I am, there are no free Developer ID certificates.

This disappoints me — I cannot justify enrolment in the paid program for DfontSplitter for Mac, which doesn’t generate me significant donation revenue at all. This means I cannot sign DfontSplitter for use with Gatekeeper, which degrades the experience for Mountain Lion users of the software, and maybe even puts them off entirely.

I am definitely in favour of security measures that put the control in the hands of the user. I cannot, however, get behind a system which appears to discriminate against all developers who are not in a position to join Apple’s certification programme. I am left disappointed, and my app is left unsigned.

Photo is Barbed Wire Twilight, by Orin Zebest. Licensed under CC-BY 2.0 GB.

In my most recent article for For Mac Eyes Only, I ponder the implications of the remarkably speedy scheduled release of Apple’s OS X Mountain Lion on the longer term viability of older Mac hardware. Mountain Lion is due to arrive just a year after the release of Lion.

We now await OS X 10.8, Mountain Lion. Scheduled to be released a mere year after Lion, we are promised even more features ‘inspired by iPad’.

Wait a second. What was that? It is due to arrive this summer. Just one year after Lion was released.

A new release of OS X hasn’t come so quickly since the operating system was very young and was still being established and stabilised.

This strikes me as quite a shift, and it brings me to an important issue — how does this affect the lifespans of the Apple products we buy?

You can read the full article over on the For Mac Eyes Only site.

The security landscape for Mac OS X is changing. It has been for some time, but every now and then, an event comes along that highlights it.

I am thoroughly disappointed with how tardy Apple can be with releasing security updates. Java has been one of the components most visibly neglected in terms of timely patches. The recent ‘Flashback’ trojan for OS X exploited old, well-known vulnerabilities in Java that Apple had failed to promptly patch.

Java on Lion is deprecated, and is no longer installed by default. However, some upgrades from Snow Leopard bring Java along with them, and some users have manually installed Java for compatibility with certain applications.

If you do not know that you need Java installed on your system, do not install it. That is the best way to mitigate any security threat that would try to leverage a Java vulnerability to get into your system.

On Lion, however, once Java is installed, it does not seem to be possible to completely remove it.

What you can do is change the permissions on the relevant files so that it is ‘neutered’ and cannot run at all.

How to Completely Disable Java for Lion

I don᾿t recommend you disable Java on Snow Leopard. It is part of the operating system there, not an optional add-on component. I have not tried this process on Snow Leopard. Proceed to disable Java like this at your own risk (even on Lion)!

While logged in as an administrator user, open Terminal from Applications > Utilities.

Type the following commands in, pressing Enter after each one. You might be asked for your password.

sudo chmod 000 /System/Library/Java/JavaVirtualMachines/
sudo chmod 000 /Library/Java/JavaVirtualMachines

What these commands do is change the permissions mode to 000 on these Java files, meaning that no users have any permissions to even enter these folders, let alone read any files in them. This stops Java from running.

You can test that it is working, or, rather, not working, by now attempting to load Java Preferences in Applications > Utilities. You should be told that Java is not installed, and invited to install it. Click Not Now.

Re-enabling Java

If you suddenly find that actually you do need Java again, simply run the same commands in Terminal, but with the permissions mode 755 (the folder’s owner can read, write, and enter the directory, and everyone else can just read and enter the directory).

sudo chmod 755 System/Library/Java/JavaVirtualMachines/
sudo chmod 755 /Library/Java/JavaVirtualMachines

It should spring back into life!

Infected?

If you were unfortunate enough to be infected by Flashback (even if you did not type the Administrator password when it prompted), F-Secure has some instructions on its detection and removal. (Hat tip to @bldngnerd.)

Since Snow Leopard, each new release of Mail.app (recently updated with 10.6.5 and now 10.6.7) and the Message.framework it depends on changes a ‘plugin compatibility’ UUID and suddenly breaks any plugins or extensions you have enabled in Mail.app. The developers of each extension have to update each and every one manually, and can’t do so before the new software from Apple is released.

If you can’t (be bothered to) wait for the updates from your plugin developers to arrive, however, and are confident that the plugin will work with the new version, you can hack said plugins and force them to be re-enabled inside Mail.app using the following method. Here I’ll be working with GrowlMail 1.1.2, but this should work for most Mail.app plugins.

A word of warning — not only does this involve editing the plugin’s files, which if you get it wrong could break that plugin and force you to download and install it again, it is possible that your plugin really isn’t compatible with the new version of Mail, in which case it could cause more serious problems. Back stuff up before trying this — you should be doing so anyway.

» Read the rest of this post…

I don’t have a single default browser that I use. I use both Firefox and Safari as my primary browsers (and I throw SRWare Iron into the mix sometimes too).

Of course, my primary OS, Mac OS X, requires me to pick one browser that is used by default when I click on a link in another application. The browser that I want to use for any given link will differ, however. I might have one of the two browsers open right now and want to use the one that is open rather than opening a new application, or it might be a potentially untrusted link, where I’ll want to use Firefox (with my restrictive NoScript configuration) rather than Safari.

Enter Choose Wisely. It is a small application which you set up with the browsers you might want to use. You then set Choose Wisely itself as your default browser. Whenever you click a link, it will pop open.

You simply click the browser you’d like to use on this occasion and the link will open as normal in your chosen browser. It is a really light, simple solution to this problem that takes no more than a second extra of your time.

Initial Setup

When you initially launch the application, there will be no browsers in the window. Go to your Applications folder in the Finder and just drag and drop the browsers you would like in the list onto the window.

You will also want to set Choose Wisely as your default browser. To do this, open Safari. In Safari > Preferences, go to the General divider and select Choose Wisely under Default web browser.

Conclusion

As I said, it is a wonderfully simple solution if, like me, you want to use different browsers for different tasks and on different occasions. Some will find it an annoying extra step — and if you’re happy with just the one browser, it won’t be any use to you at all.

But if you do like to pick and choose browsers on a per-link basis, this is a great solution. You can download it from this page (scroll down to the Download section).

Not too long ago I put together a screencast which aims to introduce Mac users who haven’t played with Terminal or command lines before and try and explain some of the initial concepts and to get doing a few things.

I’d love your feedback on the screencast — you can watch it either at its page on The Stealth Mac podcast website or Part 1 and Part 2 on YouTube.