Wednesday, November 22, 2017

Plan on using Face ID on iPhone X in your iOS app? You must include NSFaceIDUsageDescription in your Info.plist

I’ve already shipped an app that is accessing Face ID on iPhone X, but while testing an unrelated feature the other day, I saw the alert on the left. I thought I had read everything that I needed to about Face ID implementation, but this had slipped past me.









I parked it for a while, but I happened to open the docs on LAContext on an unrelated issue when I saw the Important information on the right.



When you click on NSFaceIDUsageDescription you see the description on the left. I didn't experience any forced app quitting behavior on device or simulator, but your experience may vary.





With NSFaceIDUsageDescription added to Info.plist, and a key of “Secure Account Access” like in the right screenshot, users will see a prompt like the one on the right when the app tries to access Face ID the first time.









Glad I caught this in the “one to fix all the iPhone X issues” release of the app I’m working on.

Sunday, October 01, 2017

How I was Accidentally Credited by Apple on a macOS Security Update

curl

We would like to acknowledge Dave Murdock of Tangerine Element for their assistance.

That’s from the end of About the security content of macOS Sierra 10.12.6, Security Update 2017-003 El Capitan, and Security Update 2017-003 Yosemite.

I wasn’t aiming to obtain such credit, all I did was File a Radar on curl.

Why?

I have no end of trouble downloading Cocoapods, Ruby Gems, Node modules, using Terminal at my day job.

They have a proxy server connected to my Active Directory credentials. For GUI based apps, macOS combined with a little Apple utility called Enterprise Connect configures everything as soon as I make a connection to the network.

However, anything that is strictly command-line is not guaranteed to work.

A bunch of co-workers and I have taken matters into our own hands and written a script that runs in our .bash_profiles. It sets these environment variables when started a shell automagically based on the current username and password:

http_proxy
https_proxy
no_proxy

Both http_proxy and https_proxy have traditionally been set to the same thing, a proxy server like http://proxy.company.com which is only available inside your company. Even the https_proxy variable is configured to hit an unsecured HTTP server.

During an earlier version of the script, I had accidentally set https_proxy to https://proxy.company.com and things were breaking.

Turns out, curl couldn’t support HTTPS proxies until late 2016, and macOS 10.12.5 hadn’t been updated to curl 7.52.0 or later to add support.

So I filed a radar…

But Wait There’s More!

Turns out, curl 7.54.0 or later closed a number of CVEs and I mentioned that in my radar.

Fast forward 2 months after I filed the radar, and Apple Product Security emails me to ask if I’d like credit.

I hesitated at first, not knowing what, if any, ramifications being publicly listed on an Apple Security listed might have.

Ultimately, being credited was just to cool not to do, so I did.

Still More to Do

While curl has been updated, unfortunately my problems persist. Appears the Generic Security Services Application Program Interface (GSSAPI) somehow occasionally selects the wrong way to present my credentials to the proxy server and I get connection errors.

I’m updating to macOS High Sierra right now hoping that something has changed to resolve this issue, but if not, I’ll be filling another radar.

Though the public Bug Reporter interface recently got a much needed overhaul, the system is still far from perfect. 

I’m truly baffled why Apple doesn’t build macOS and iOS apps that developers can use to collect the required information and file with far less work. I bet they’d get a lot more high quality bug reports. I’ve filed a radar on a radar app.

However, I’ve seen enough bugs fixed that I was the original reporter to feel my time is worth spending on filing radars.