Solipsism Gradient

Rainer Brockerhoff’s blog

Browsing Posts in Software

If you’re using Quay, please check out the release notes and install this new version as soon as possible.

Note that older versions of Quay will break on Mountain Lion, giving you a persistent error message. Sorry about that, but the installation should be painless. Quay is now signed with my Developer ID for Gatekeeper compliance. And with RB App Checker Lite this is easy to verify. 😉

That said, I’m hard at work to get new stuff out in time for Mountain Lion (rumors say that will be sometime between July 19 and 31). Details are still fluid but I’ll post them here as soon as I get the basic functions working reliably.

My main concern is keeping my promise of upgrading paid users of Quay and XRay to the new stuff. This is unfortunately impossible with the Mac App Store, but not all utilities will be there, so i still think it’s going to work out.

Update: while this runs fine on 10.8 in my tests here, it may not behave well on the new Retina display (remember this was originally coded for 10.5!). I’ll try to do some tests tomorrow.

Update 2: OK, tests show it’s not Retina-compatible, so I’ve uploaded a new build with the “Open in Low Resolution” option checked. My apologies for the oversight. It’s not at all clear – looking at the source – how I could make it compatible both with high-resolution and 10.6.8 on short notice. And it’s still a 32-bit application, too.

Summing up: Quay is getting elderly and this update is, really, only for current users who like it. Don’t expect it to be updated again. But, as I said above, cool new stuff will soon be out. Suggestions welcome!

RB App Checker Lite 1.0.1 (187) has just gone live on the Mac App Store, and the corresponding Developer ID-signed build (186) is now available for direct download.

In the last month, almost exactly 1000 copies have been downloaded from the Mac App Store, and about 300 copies have been downloaded directly from my site. Not bad; the download curve shows the usual decaying exponential shape, but it is decaying much more slowly than I thought it would. And this with no marketing except for Twitter and a single press release.

Since both versions are free, I suppose that the main reason for users preferring the MAS version is the ease of updating; the direct-download version doesn’t have automatic updating, nor is it cost-effective to have it now. The popular Sparkle framework is over double the size of the entire application, and does much more than I need. When a non-MAS RB Utility comes out, it will have automatic updating, and that will automatically appear in all direct-download RB Utilities; a benefit of using a common app framework.

Update: here’s a common use scenario for RB App Checker Lite: an automatic updater starts and requests your administrator password. Is this safe? Easy to check:

  • Command-click on the updater’s icon in the Dock; this will show the updater’s icon in the Finder;
  • Right-click on this icon and select the “RB App Checker Lite ” service;
  • RB App Checker Lite’s results should tell you if the updater can be trusted or not. Be especially wary of unsigned or self-signed updaters that ask for your admin password, unless you’re really sure!

Now in the MAS!

No comments

Yesterday evening RB App Checker Lite was approved for sale in the Mac App Store. Whew; it’s been a difficult couple of weeks, but it’s done. Now to relearn my php-fu and do a better product page, and of course restart work on other apps in the RB Utilities suite. Next in queue are “RB File Counter”, “RB File Alias” and the non-lite version of RB App Checker.



News on the RB App Checker Lite front. Version 1.0 (179) is out; check the product page for release notes.

The previously published version was 1.0 (171) – note I’m just incrementing the build number for now, this is mostly for keeping this version in sync with the one submitted to the Mac App Store.

Speaking of the MAS, my first submission was finally rejected for a bug with Services registration (after 7 days “Waiting for Review”, which is not too bad). So I’ll be resubmitting tonight, with that bug hopefully solved, and several new others fixed and new features added.

The most interesting new feature is checking for embedded provisioning profiles.  iOS apps will always have one, but you normally won’t see such a thing in a Mac application. However, both .xcarchives and apps “built for archiving” will have an embedded profile (unless you’re signing with your Developer ID).

Feedback welcome!

Update I: ehrm, make that version 1.0 (181). Only the icon has changed; Apple objected to my using the “generic application” icon as part of my own.

Update II: yes, the new icon is just a stopgap, will be redoing the details in the next build.

RB App Checker Lite is now functionally complete and I decided to simultaneously publish the 1.0 version here – it’s free – and on the Mac App Store. In the “About Box” the version appears as 1.0 (171).

If you already have one of the public betas somewhere on your hard drive, better remove it before unzipping this version – otherwise the Services Manager may become confused about the correct version to run.

One interesting new feature is that you now can run RB App Checker Lite on Xcode archives (.xcarchive bundles). This will also work for iOS archives, by the way.

I’m still working on more and better documentation and perhaps some sample screenshots on the product page. I suppose I also should add a new support forum.

Regarding the Mac App Store version, before actual review there still seems to be some problem regarding developer profiles and certificates — somewhat ironical for this specific application! Still, this being my first submission to any of the App Stores, it’s to be expected. Stay tuned for news.

Inspired by my recent musings about OS X 10.8 – specifically, the need for a way to check application signatures – I’m releasing the first public beta of RB App Checker Lite. Please follow the link to download.

RB App Checker Lite will be an easy way for anyone to check any executable – application, command-line tool or framework – for signatures. Also, for an app downloaded from the Mac App Store, it will show you the receipt and check everything for validity.

This is also the first of my forthcoming RB Utilities application suite. Here’s the application icon:

The icon series was designed by Sérgio Bergocce. The cube will be common to all applications, my logo is of course on the left, and the right-hand side will symbolize what each app does; the colors will try to symbolize price and geekiness level. 🙂 In this case, light blue alludes to the “Lite” part, and of course that means the application will be free.

I’ll try to distribute all free utilities over both the Mac App Store and my own site; non-free utilities are intended to be MAS-only, if possible. The ultimate intention is to substitute my very old XRay utility by a group of small, focused programs. More on that later…

I had just published my previous post about Mountain Lion and Gatekeeper when Apple announced the third postponement of the sandboxing deadline for the Mac App Store, this time until June.

This was expected; given the announcements and the changes in the sandbox details (including some unannounced ones which I can’t comment on), a postponement was inevitable. In fact, my hunch is that at WWDC 2012 a final postponement will be announced, to coincide with the golden master of 10.8; or, at the very least, 10.7.4 will be back-fitted with the same Gatekeeper and sandboxing capabilities. This latter option has a potential pitfall; Xcode doesn’t like applications setting their minimum system version to a point release.

A brief recap of the sandbox is in order. If the developer turns on sandboxing, the application will run inside a protected environment. The user’s home folder is substituted by a per-application container where parts of the original home are reflected by symbolic links. Certain folders, such as ~/Library and ~/Documents, are not reflected. A sandboxed application’s system calls are closely monitored and restricted. The intention is that the application cannot interact with other applications, or with other app’s documents – not even with their preferences. However, some parts of the file system can always be read, basically to allow the application to use system resources.

These restrictions can be selectively eased either by a signaled user intention or by a list of so-called “entitlements” set into the application signature. Entitlements can allow access to iCloud, to selected hardware such as networks, cameras or printers, to user databases such as calendar or address book, or to parts of the file system outside of the application container such as music, picture or movie folders. Access to files can be granted as read-only or read-write.

User intentions can be signaled by actions such as dragging & dropping icons from the Finder onto the application’s icon or windows, or by selecting files/folders from the standard open or save panels (and there are entitlements for that option). This opens a temporary breach in the sandbox for that run; starting with 10.7.3, this access permission can be stored into a bookmark file for later use by the application.

Temporary exemptions can be granted to allow the application permanent access to any part of the file system, however Apple advises that such exemptions may not be allowed for apps in the Mac App Store.

Many other actions are restricted by design, and there are no entitlements to allow sandboxed apps to send AppleEvents to other apps, to use the Accessibility APIs for controlling other applications, and so forth. Add that to other restrictions already in place for the Mac App Store – such as not allowing privilege escalation by asking for an administrator password, system preference panels, etc. – and it’s understandable that developers are viewing the forthcoming sandbox requirement with trepidation and even anger.

On the other hand, for the user, sandboxing has its advantages. Losing data by program bugs or malicious code is restricted to the few places where read-write access is granted. Applications that “phone home” won’t be able to do so unless network access is allowed by an entitlement. If the entitlements are carefully chosen and restricted to the exact functionality of the app, everything should be well.

Unfortunately, the current entitlements are relatively few and more related to Apple’s initial ideas about what type of app should be on the Mac App Store – a game or relatively simple document-based application, perhaps. Now that Gatekeeper will be allowing “identified developers” to sign applications, Apple should also encourage these developers to use the sandbox. Well-known developer Daniel Jalkut says that the sandbox should be expanded:

Apple should embrace the utility of sandboxing by shifting their focus away from sandboxing only Mac App Store titles, to a strategy that would sandbox virtually every Mac app, inside the store or out…

To increase adoption, Apple should expand the current list of entitlements until it covers every reasonable behavior that users expect from Mac apps…

Finally, Apple should take a cue from its own Gatekeeper approach. By incorporating sandbox information about apps into the forthcoming app security preference pane, they will empower users to understand application intentions.

I agree fully with Daniel but would like to expand his proposal even more. We need more fine-grained entitlements that also encompass things that are currently done by older methods. For instance, to interact with other apps over the Accessibility APIs, application’s binaries need to be blessed with the old Unix setgid bit – or the user has to be oriented to allow all and any applications to do this. This would be easily solved by a specific entitlement. No doubt some entitlements might be restricted to administrator-level users. All in all, expanded entitlements will be in the general interest.

All that’s missing is an easy way of communicating to the user what entitlements the sandboxed application has set into its signature. Rather than do this in the security preference pane, I’d like to renew the idea I mentioned in my previous post: an information panel that’s shown on the first run for a signed application (and easily found by the user for re-checking thereafter). Besides showing information about the code signature and the authoring developer, this panel should also show a concise explanation of the entitlements requested by the application; with that information, the user can fully decide whether running that app will be worthwhile. Hm, why does this game want access to my Address Book, to the Internet, and read/write access to my entire hard drive? Looks suspicious…

This would take care of applications signed by identified developers. Unsigned applications that run without a sandbox should rightly be viewed with some suspicion. I don’t see many arguments in favor of anonymously-authored applications, but in any case, with the upcoming model, the user always has the option to make exceptions.

There remains great controversy about what was, until a few days ago, the main use for the sandbox: in Mac App Store applications. There was no incentive for non-MAS apps to be sandboxed, and Apple seemed to be unyielding in expanding the available entitlements – the gist on the developer forums seemed to be “either fit in the sandbox as it is or don’t sell over the MAS”. There are temporary exceptions and some (very few) developers got personal workarounds, but it all feels very constraining. In my opinion, it’s extremely worthwhile for developers to file feature requests for the sandbox outside the MAS. After all, it’s in Apple’s own interest to see wider sandbox adoption, and the hope is that some of those new entitlements will – after some time – flow back to benefit MAS apps.

Who knows, perhaps Apple will, in time, allow identified developers to sell iOS apps outside the App Store? It all depends on how successful that model is on the Mac. After all, confluence should go both ways!

Update: I just found Uli Kusterer‘s article about the sandbox which makes several of the same points, including one I’d forgotten to mention above: entitlements could easily refer to other applications just by mentioning their bundle ID (and perhaps, distinguishing between sending AppleEvents to that app, accessing their preferences or sandboxed files, and so forth).

New Cat in the Sandbox

No comments

In a surprise move by Apple, Mountain Lion (aka Mac OS X 10.8) was announced early and in an unorthodox manner.

Their new infrastructure seems to be working well – I downloaded and installed the beta very soon after the announcement. It’s working well (for a beta) in a VMware virtual machine after following this hint.

Let me comment briefly on the “iOSification of OS X” question. Having consistent app names (and, to some extent, user interfaces) between similar applications on both iOS and OS X is a good thing. Greater integration with iCloud was also pending, and here too users need a consistent interface on both platforms. Beyond that, there seems to be little evidence that the operating systems themselves will suffer anything but a benign cross-pollination of features and APIs.

As a developer, I’m more interested in what code signing, the upcoming Gatekeeper and sandboxing requirements for the Mac App Store mean for future applications.

Code signing has been a feature of Mac OS X for some time now. The details are tricky but, in essence, executable code can be signed using an “identity” backed by a “trusted” chain of certificates. Such a certificate is a variation of the ones deployed for “trusted” websites – those whose addresses start with “https:”. Obtaining a so-called “self-signed” certificate and signing an application on OS X is quite easy, and several of my applications have been signed in that manner.

On the downside, anyone can strip such a signature and substitute another one; and checking for that is not easy for the user. Here’s part of my current Klicko product page:

To check that Klicko’s signature is intact, open Terminal, paste in the following command, and press the Return key:

codesign -dvvv -r- /Library/PreferencePanes/Klicko.prefPane

(assuming that you installed Klicko for all users; otherwise, type a tilde (~) before the /Library part.) You should see several result lines in the Terminal.Authority=Rainer Brockerhoff should be present, and identify the author. The last line should end with …root = H”4cbb97c74336f7ee6aa566122a5e7688e1c725dc” and uniquely identify the author’s signature. Now run the following command:

codesign -vv /Library/PreferencePanes/Klicko.prefPane

If the Klicko bundle is intact, this should display valid on disk; otherwise you’ll see code or signature modified. In the latter case, throw it into the Trash.

Not something that a non-techie user would do; and the system doesn’t (yet) complain if you try to run an unsigned application (or one whose signature or executable has been tampered with). Even so, on current systems there are benefits to running signed code: parental controls and keychain access are example cases.

Code signing has been mandatory on iOS from the very beginning – it won’t run applications not signed by a registered developer, backed by Apple’s own trusted certificates. The whole “jailbreaking” paradigm stems from that feature: normally, only apps from Apple’s App Store may run, and Apple can revoke an application’s certificates if the application misbehaves.

Enter Gatekeeper. As far as is known, it has three levels, selectable by the user in System Preferences, allowing the user to run applications that come from:
1) the Mac App Store only (same as on iOS devices);
2) from the Mac App Store and identified developers;
3) from anywhere (same as on current and previous systems).
It’s of course unknown which of those levels will be default when 10.8 goes golden.

Gatekeeper is triggered by the well-known “quarantine” attribute set on applications and disk images downloaded from the Internet. After the usual dialog alerting you to that fact, if you’ve set Gatekeeper to level 1 or 2, the application’s signature is checked; if it’s not backed by the corresponding trusted Apple certificate, a further dialog advises you not to run that application. There’s no override option unless you opened the application from the contextual menu (instead of double-clicking). Also note that this doesn’t happen with applications copied from external drives.

Parts of Gatekeeper are already available on 10.7.3 but must be turned on with a Terminal command. The most restricted level isn’t available, and for an improperly signed app the complaining dialog curtly advises you to “move [the app] to the Trash”; it even offers a button to do so. Although this dialog doesn’t seem to occur on 10.8, some developers are considering it a bad sign of things to come.

But it is the intermediate Gatekeeper setting which is the most important; hopefully it will be the default. So what is meant by “identified developers”? Currently, this is someone who paid the annual $99 fee to be part of Apple’s Mac developer program. As I am in that position, I’ve already requested and downloaded my code signing certificate, and will use it to sign my future applications – those published outside the Mac App Store.

The benefits to myself are obvious. Anybody who downloads my applications through the usual channel – directly from my website – can be assured that it is signed by myself, that it hasn’t been tampered with by a third party, that I’m a registered developer, and that Apple certifies that all this is true. Still, some additional care needs to be taken, both by Apple and by the user. Specifically, when 10.8 comes out it should have an easily accessible information window containing the following information: (sorry, no time to make a graphic mockup)

<Application name and version> is signed by <developer name> developer ID number.
<Link to developer/application site>
<List of certificates and their expiration dates>
Apple disclaimer (for non-Mac App Store applications).

This information should be shown on first run – perhaps on request from the “quarantine” dialog – and from somewhere in the Finder. Note also that Apple can revoke a developer’s certificate; it’s as yet unknown if that will affect already-downloaded applications (as I think it does on iOS) or not.

As I said, the user can take steps to run the application even if Gatekeeper advises against it. Unless this option is removed when 10.8 goes out of beta – and it would make no sense at all for Apple to remove it – it’s a welcome step for serious developers. And it’s a practical intermediate solution for applications or system plug-ins that don’t fit into the Mac App Store’s restrictions; specifically, regarding the impending MAS requirement for turning sandboxing on. More on that in my next post.

[Updated to fix an error regarding Gatekeeper on 10.7.3.]

Photos licensed by Creative Commons license. Unless otherwise noted, content © 2002-2022 by Rainer Brockerhoff. Iravan child theme by Rainer Brockerhoff, based on Arjuna-X, a WordPress Theme by SRS Solutions. jQuery UI based on Aristo.