Archive for March 23, 2018

Friday, March 23, 2018

Swift Integration Traps

Daniel Jalkut:

A worse consequence is the number of pitfalls that ABI instability present, that are difficult to understand intuitively, and in many cases impossible, or at least dangerous, to work around. These pitfalls lie mainly in areas where developer code is executed on behalf of a system service, in a system process. In this context, it is not possible for developers to ensure that the required version of Swift libraries will be available to support their code. Game over.


But once you’ve written the code to draw those fancy graphs in Swift, you’re locked out of using that code from a QuickLook Plugin. Worse? Finishing touches such as supporting Quick Look are liable to come later in the development of an app, so you’ve probably gone through the decision-making process of writing your app in Swift, before realizing that the decision effectively cuts you off from a key system feature.

Spotlight importer plug-ins face the same issue.

Update (2018-03-30): Daniel Jalkut:

I think it’s officially impossible to offload QuickLook plugin to an embedded XPC service in order to use Swift.

High Sierra Stored APFS Volume Passwords in Log Files

Sarah Edwards (tweet):

I’ve been updating my course (Mac and iOS Forensics and Incident Response) to use new APFS disk images (APFS FTW!) and came across something that both incredibly useful from a forensics perspective but utterly horrifying from a security standpoint.


I used the following command to watch my unified logs in the Terminal while the process above was doing its thing:

log stream --info --predicate 'eventMessage contains "newfs_"'

…and there we have it, a plaintext password!

It’s fixed in macOS 10.13.2 [Update (2018-03-25): Actually not; see below.], but I wonder how many passwords are still stored in logs somewhere, e.g. in sysdiagnoses uploaded to Radar. Also, judging from the usage message for newfs_apfs, it looks like the fix may have been simply to suppress this particular log message. It still takes the passphrase as a command-line argument, so it might still be exposed in other ways, rather than using the more secure -stdinpass method that hdiutil uses.

Howard Oakley:

If you:

  • encrypted an APFS volume using macOS 10.13 to 10.13.1 using Disk Utility, and
  • have a copy of the unified log collected at the time of that encryption, in a logarchive

chances are, that logarchive will contain the passphrase recorded in plain text. You therefore might like to destroy or encrypt that logarchive.


I am not aware that Apple has issued any warning of this potential security breach. Given that the bug appears to have been recognised and fixed, that seems more than a little remiss.

Previously: Encrypted APFS Volume’s Password Exposed as Hint, High Sierra Bug Allows Root Access With Blank Password, App Store System Preferences Can Be Unlocked With Any Password.

Update (2018-03-25): Moe Lassus:

Reproducible on 10.13.3.

Howard Oakley:

Thanks to @moelassus, who reported seeing this bug persist in 10.13.3, and Sarah Edwards, we have established that this is a 100% reproducible bug in 10.13.3. It does not, any longer, affect the creation of new encrypted APFS volumes, but occurs when an existing unencrypted APFS volume is encrypted, by erasing just that volume in Disk Utility.


When Apple ‘fixed’ the original bug, which occurred when creating a new encrypted APFS volume, it clearly did so by accident, and was unaware that the change that was made to the volume creation step blocked the entry of the plaintext password in the log. Consequently, another instance in which an almost identical call was made by diskmanagementd, to newfs_apfs to make an existing volume encrypted, was left in the code. It is that call which is currently appearing in the log.

Previously: Sierra Log Littering.

Update (2018-03-30): Sarah Edwards (Hacker News):

The previous examples were found in the unified logs which can hang around for a few weeks, this new example stores the exact same information in the system’s /var/log/install.log. I have found that the install.log will only get wiped out upon major re-installation (ie: 10.11 -> 10.12 -> 10.13), therefore these plaintext passwords will hang around for quite a bit longer than a few weeks! I had entries dating back to when I originally installed High Sierra on this system back in November of 2017!

Update (2018-03-31): Howard Oakley:

Although 10.13.4 fixes this leak, it still only does part of the job. It doesn’t roll the install.log to remove all those old plaintext passphrases, which remain in the log for all to see. What is worse, to my mind, is that it doesn’t stop diskmanagementd and associated processes from writing to install.log.

Update (2018-04-01): Howard Oakley:

When Apple introduced its new unified log in macOS Sierra, almost every other system log went silent (other than in residual entries by legacy products), apart from install.log. Why that was spared has never been explained by Apple, which suggests that it wasn’t part of its plan. This has now proved helpful in many situations, as sysadmins and others can still examine installation and update problems without having to do battle with thousands of other entries in the unified log.


One potentially good reason for continuing to write to a traditional log as well as the new unified log is the weakness of Apple’s tools – then and now – for accessing the unified log. Console still lacks any ability to browse history in the unified log, except when the live log is converted into a logarchive, and even then it is hard to use. install.log remains far more convenient to examine, and the engineers working on those parts of macOS which have been writing to it have probably been very grateful that they were not forced to work with the unified log alone.


Returning to the accident chain behind this, I can see the following links[…]

Sarah Edwards:

APFS encrypted volumes can be created on the disk level as well as the volume level and it truly seems to make a difference. Please also test if you find (or don’t find) the results in the Unified logs and/or the install.log or neither (and god forbid any other locations you might come across!). I’m also consistently using the “Erase” button versus the “Partition” button.

Update (2018-05-11): See also: Paul Ducklin.

Apple Stores Suffer From Customer Complaints, Long Wait Time

Kate Taylor:

A recent trip to a New York City Apple Store by Business Insider’s Avery Hartmans revealed a chaotic, hellish mess.

The store was packed with people. It was unclear which employees were available to help and which were otherwise occupied. Without a reservation, it was nearly impossible to get help at the Genius Bar. To make matters worse, it could be days before there was an open reservation.

This isn’t an isolated issue. Social media has been flooded with complaints about Apple Stores in recent months.


“We haven’t been able to keep up with traffic since I started 8 years ago,” a senior Genius at a small store in the Midwest told Business Insider. “I wouldn’t even walk in the store because of how crowded it gets. During Christmas [season] you can hardly move.”

Via Mike Rundle:

Buying something at an Apple Store, ostensibly the most important interaction at any type of store, is annoying and involves wandering aimlessly to find an employee. Not fun at all.

Neven Mrgan:

My last five visits have been complete disasters. It was worse than going to Best Buy in the 90s. If any other business had a waiting area consisting of “go stand in that corner,” we’d laugh at it mercilessly.

Previously: Angela Ahrendts’s Plan for Apple Retail.

Dealing With Weak in Closure-based Delegation

Oleg Dreyman (via Joshua Emmons):

Let’s look at the core of the problem: 99% of the time, when assigning a delegation callback, there should be a [weak self] capture list, but nothing is actually preventing ourselves from omitting it. No errors, no warnings, nothing. What if instead we could force the correct behavior?


Leveraging the power of Swift generics, we can do better:

struct DelegatedCall<Input> {

    private(set) var callback: ((Input) -> Void)?
    mutating func delegate<Object : AnyObject>(to object: Object, with callback: @escaping (Object, Input) -> Void) {
        self.callback = { [weak object] input in
            guard let object = object else {
            callback(object, input)

Alexa’s New “Brief Mode”

Sarah Perez:

For example, if you ask Alexa to turn on your lights today, she will respond “okay” as she does so. But with Brief Mode enabled, Alexa will instead emit a small chime as she performs the task.

Via Nick Heer:

I would love an option like this for Siri on all of my devices. It indicates a great deal of trust Amazon has in its own product for them to reduce Alexa’s feedback to a simple audio chime.

Kickstarter and Business Advice

Max Temkin:

Simplify your project as much as possible so that backers have an easy decision to make. If you have 30 levels of rewards, it can become paralyzing. Just confidently offer the best version of what you’re doing.


Don’t do any other gimmicks, tricks, or hacks to get money from Kickstarter. They will almost always backfire and make you look like an asshole. The whole point of Kickstarter is to test out your idea and see if it connects with an audience. If it does - great! You get to make your thing. If it doesn’t - that’s okay too! It’s an opportunity to figure out what didn’t work and fix it.

For the love of god figure out how much shipping is going to cost before you launch.


My biggest fear about dispensing advice and platitudes is that people will just try to do the same things that I did. But of course that won’t work. Working through the anxiety of not knowing what to do and emerging on the other side with an authentic understanding of what’s special about your game is not something you can hack your way out of; it is the creative process.

Apple AirPods: the Audiophile Review

Vlad Savov:

But here’s the thing: using the AirPods isn’t merely a “wireless EarPods” experience. Or rather, there are surprising aspects to making the EarPods wireless that I didn’t appreciate until I used the AirPods. My impression of the EarPods has always been colored by how loosely they sat in my ears. The merest tug or tension on their wire would unseat them. Well, without a wire, that entire issue is obviated, and moreover, the stem of the AirPods sits flush with the side of my face and helps to anchor them in place. I have run with the AirPods, I’ve done push-ups, lifted weights, and moved around vigorously without either one coming close to falling out. Your mileage will, of course, vary, but I can’t say the same about Google’s Pixel Buds or the majority of other earbuds on the market, wired or wireless.


I say the AirPods aren’t technically amazing, but that’s only when comparing against existing standards for sound quality. In the category of truly wireless earbuds, the AirPods are the best I’ve yet heard.


Maintaining a consistent and reliable Bluetooth connection, the thing I actually care about, is still sadly uncommon among truly wireless buds, so Apple’s wireless earphones are easy to recommend even to Android phone users.

See also: Kirk McElhearn.