Haskell development in Mac OS X after Gatekeeper

Tom Murphy

19 Feb 2012 19 Feb '12

7:01 p.m.

Does anyone know what this will mean for the future of Haskell development in OS X?: http://www.apple.com/macosx/mountain-lion/security.html I'm particularly interested in what it'll mean for 0) Distributing non-Cocoa-built apps, even if you're approved by Apple 1) Writing software for widespread use (a security setting is to only run software from the App Store, and I'd like to have my software function on users' computers.) 1.0) Aren't you unable to put software under the GPL or certain other open-source licenses on the App Store? amindfv / Tom

Show replies by date

Austin Seipp

19 Feb 19 Feb

7:31 p.m.

On Sun, Feb 19, 2012 at 6:01 PM, Tom Murphy wrote:

...

0) Distributing non-Cocoa-built apps, even if you're approved by Apple

Do you just mean binaries that you expect users run under /usr/local/bin or something, not app bundles? If that's the case, I cannot say if the same restrictions will apply. From my reading on the issue though, in the case of an app bundle, is that you don't have to be 'approved' per se by Apple. By having a Developer ID, you have a key you can then sign your binaries with. A binary signed with a valid key from Apple will run on any OS X machine, provided the Gatekeeper settings allow it - should that app later be discoverd as malware, or the *key* is used to sign some other piece of malware (because maybe it got stolen,) they just blacklist your key and no users can then run it. As a result, none of your applications you distribute outside of the Mac App Store have to be 'approved' - you just need to sign the binaries with your key before distributing them. It's blacklisting based, not whitelisted.

...

1) Writing software for widespread use (a security setting is to only run software from the App Store, and I'd like to have my software function on users' computers.)

Settings like this are beyond your control, it's just a fact of life. This basically affects every single thing that *isn't* in the Mac App Store, and if users decide to enable this, there's nothing you can really do other than telling them to change gatekeeper settings. Users can always over-ride this on a temporary, per-app basis, by holding control and clicking on the binary instead.

...

1.0) Aren't you unable to put software under the GPL or certain other open-source licenses on the App Store?

Someone more familiar with the AS on Mac/iOS will have to comment here. I'm fairly certain the iOS store does not do GPL'd applications, but I don't know about the Mac App Store. -- Regards, Austin

Tom Murphy

9:19 p.m.

On 2/19/12, Austin Seipp wrote:

...

On Sun, Feb 19, 2012 at 6:01 PM, Tom Murphy wrote:

...
0) Distributing non-Cocoa-built apps, even if you're approved by Apple

Do you just mean binaries that you expect users run under /usr/local/bin or something, not app bundles? If that's the case, I cannot say if the same restrictions will apply.

Actually, what I was more concerned about was the ability to distribute a "full" Mac application, with a GUI, made with a method other than calling Haskell from Objective-C. It seems that *none* of these applications will be usable by anyone except users with all security settings turned off (it doesn't sound great in a user manual: "Every time you run this program, be sure to turn the malware-detector all the way off") The reason I'm concerned is that having a security signature requires a membership to the Apple Developers program, which is exclusively for XCode [0]. Isn't it logical to assume that the signature-"bundling" process [1] occurs within XCode? (I'm assuming the "digital summary of the contents of the application" is a hash, which (I think) would imply that XCode-compilation would have to be the final step in the development chain) Which (again, unless I'm reading it wrong) means that most Haskell OS X GUI work (incl. FRP) goes out the window?! amindfv / Tom [0] Not to mention $100 every year! [1] "Digital signatures are created by combining a secret key known only to the developer with a digital summary of the contents of the application. It’s all wrapped together in an encrypted file that becomes part of the app."

Austin Seipp

10:21 p.m.

On Sun, Feb 19, 2012 at 8:19 PM, Tom Murphy wrote:

...

Actually, what I was more concerned about was the ability to distribute a "full" Mac application, with a GUI, made with a method other than calling Haskell from Objective-C. It seems that *none* of these applications will be usable by anyone except users with all security settings turned off (it doesn't sound great in a user manual: "Every time you run this program, be sure to turn the malware-detector all the way off")

The reason I'm concerned is that having a security signature requires a membership to the Apple Developers program, which is exclusively for XCode [0]. Isn't it logical to assume that the signature-"bundling" process [1] occurs within XCode? (I'm assuming the "digital summary of the contents of the application" is a hash, which (I think) would imply that XCode-compilation would have to be the final step in the development chain)

On OS X, you can sign applications or paths using any certificate you like using the 'codesign' utility, including a .app bundle. If you're going to distribute an OS X application to average users, let's face it: you're going to give them an .app bundle. You can do it yourself with a self-trusted code signing certificate already. Building LLDB on OS X for example, requires self signing in this manner, because the debugging engine needs permissions granted by the signature (AFAIK.) Regular LLDB with XCode already comes signed by Apple, obviously.

...

Which (again, unless I'm reading it wrong) means that most Haskell OS X GUI work (incl. FRP) goes out the window?!

No. Just sign your .app bundle with your Developer ID cert using codesign after the build and bundling process, and it'll work unless they only have Gatekeeper enabled to allow Mac App store apps. There's nothing you can do about this if they have it enabled if you're not willing to put it on the store, other than advise them to disable it. If it's on the store, you've already paid for the developer license and signed it anyway. The only differences mountain lion adds is that now you must at least sign those applications which you intend to distribute to regular users by whatever means, but not put them on the App Store. That's really it at the core. And tech demos and code examples will never be relevant if the target is programmers really, because developers are just going to have it disabled (equivalent to the way OS X is now, in effect.) The only two things not clear at this point, at least to me, are: 1) Will Apple require the paid development program, as opposed to the free one, if you only want to self-sign applications with a cert they trust? 2) What will the default Gatekeeper setting in Mountain Lion be? These 2 factors will control whether or not you'd have to pay and the user impact. In an ideal world, you won't require the paid dev ID (I don't know the expense of giving out certs however,) and the default setting would be App store + Dev signed. Unfortunately we'll just have to wait and see on that note. -- Regards, Austin

Manuel M T Chakravarty

21 Feb 21 Feb

3:48 a.m.

Austin Seipp:

...

The only two things not clear at this point, at least to me, are:

1) Will Apple require the paid development program, as opposed to the free one, if you only want to self-sign applications with a cert they trust?

You can self-sign applications with a certificate that you get with a free developer ID. Cf. http://daringfireball.net/2012/02/mountain_lion

...

...
Apple is calling it “Gatekeeper”. It’s a system whereby developers can sign up for free-of-charge Apple developer IDs which they can then use to cryptographically sign their applications. If an app is found to be malware, Apple can revoke that developer’s certificate, rendering the app (along with any others from the same developer) inert on any Mac where it’s been installed. In effect, it offers all the security benefits of the App Store, except for the process of approving apps by Apple.

...

2) What will the default Gatekeeper setting in Mountain Lion be?

The default is the "middle option" — i.e., AppStore and self-signed apps run. From the same source,

...

...
The default for this setting is, I say, exactly right: the one in the middle, disallowing only unsigned apps. This default setting benefits users by increasing practical security, and also benefits developers, preserving the freedom to ship whatever software they want for the Mac, with no approval process.

...

In an ideal world, you won't require the paid dev ID (I don't know the expense of giving out certs however,) and the default setting would be App store + Dev signed.

It is an ideal world :) Manuel

Jack Henahan

19 Feb 19 Feb

10:31 p.m.

As has been mentioned, it's already possible to override Gatekeeper on a per-app basis, and what I've seen so far is that it operates just as the download warning: once you get past the first check, it never bothers you again. Is it unreasonable for your users to open it that way once? As for signing, there's nothing exclusive to Xcode there. Just the `codesign` tool available as usual. Jack Henahan jhenahan@uvm.edu == Computer science is no more about computers than astronomy is about telescopes. -- Michael R. Fellows == On Feb 19, 2012, at 9:19 PM, Tom Murphy wrote:

...

On 2/19/12, Austin Seipp wrote:

...
On Sun, Feb 19, 2012 at 6:01 PM, Tom Murphy wrote:

...
0) Distributing non-Cocoa-built apps, even if you're approved by Apple

Do you just mean binaries that you expect users run under /usr/local/bin or something, not app bundles? If that's the case, I cannot say if the same restrictions will apply.

Actually, what I was more concerned about was the ability to distribute a "full" Mac application, with a GUI, made with a method other than calling Haskell from Objective-C. It seems that *none* of these applications will be usable by anyone except users with all security settings turned off (it doesn't sound great in a user manual: "Every time you run this program, be sure to turn the malware-detector all the way off")

The reason I'm concerned is that having a security signature requires a membership to the Apple Developers program, which is exclusively for XCode [0]. Isn't it logical to assume that the signature-"bundling" process [1] occurs within XCode? (I'm assuming the "digital summary of the contents of the application" is a hash, which (I think) would imply that XCode-compilation would have to be the final step in the development chain)

Which (again, unless I'm reading it wrong) means that most Haskell OS X GUI work (incl. FRP) goes out the window?!

amindfv / Tom

[0] Not to mention $100 every year!

[1] "Digital signatures are created by combining a secret key known only to the developer with a digital summary of the contents of the application. It’s all wrapped together in an encrypted file that becomes part of the app."

_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe

Jack Henahan

10:44 p.m.

In fact, since Gatekeeper, by design, can only quarantine applications acquired through the App Store or a download (or any other method which applies the quarantine flag), it may be entirely irrelevant for you depending on how you distribute. Applications on physical media are exempt, source builds are exempt, as are apps you create. Anything you've already run is similarly trusted, and anything you have to build yourself is, as well. It's fairly developer-friendly, really. Jack Henahan jhenahan@uvm.edu == Computer science is no more about computers than astronomy is about telescopes. -- Michael R. Fellows ==

wren ng thornton

22 Feb 22 Feb

12:03 a.m.

On 2/19/12 10:44 PM, Jack Henahan wrote:

...

(or any other method which applies the quarantine flag)

And you can always use xattr in order to delete that flag, if need be. -- Live well, ~wren

Richard O'Keefe

19 Feb 19 Feb

8:27 p.m.

On 20/02/2012, at 1:01 PM, Tom Murphy wrote:

...

Does anyone know what this will mean for the future of Haskell development in OS X?:

http://www.apple.com/macosx/mountain-lion/security.html

Quoting that document: Or you can install all apps from anywhere, just as you can today. You can even temporarily override your setting by Control-clicking, and install any app at any time. Gatekeeper leaves it all up to you. So in the *short* term, it makes little difference.

...

1) Writing software for widespread use (a security setting is to only run software from the App Store, and I'd like to have my software function on users' computers.)

*Short* term, the most that will happen is that people will have to say "yeah yeah I know just let me have it OK?". Already in 10.6 there was this nagging feature where you click on a downloaded document and it says "this was downloaded, do you really want to open it" and it takes a painfully long time bouncing in the dock before that dialogue box comes up. Heck, I have to provide an administrator account & password when I want to run GDB in my own directory on my own program. (And you have to love the way they removed the MacOS equivalent of truss because it was superceded by DTrace, but you have to be superuser to use DTrace...) *Short* term, it's just more continuing low-level harassment by Apple (even if perhaps with good intentions). Long term, well, there's a reason why I keep Solaris, Linux, and OpenBSD around...

Jack Henahan

9:04 p.m.

Well, the command-line tools are now available as a standalone package[1] separate from Xcode[2], so Apple's taken notice of and responded positively to large efforts like Homebrew and MacRuby. With that in mind, I don't think it's unreasonable to think this support also applies to other users of those tools, although the overall impact on source building is unclear so far. I haven't been able to find anything specific to that, yet. But Gatekeeper isn't for programmers and the like. It's for people who don't even know where the menu option is. That's why there's an option to shut it off. What's your setup like that you can't even use gdb in your own directory? That sounds unusual. And you can turn off the warning, either globally or selectively.[3][4] [1]: http://kennethreitz.com/xcode-gcc-and-homebrew.html [2]: https://developer.apple.com/downloads/index.action [3]: http://osxdaily.com/2010/03/29/disable-the-are-you-sure-you-want-to-open-thi... [4]: http://osxdaily.com/2010/09/12/disable-application-downloaded-from-the-inter... Jack Henahan jhenahan@uvm.edu == Computer science is no more about computers than astronomy is about telescopes. -- Michael R. Fellows == On Feb 19, 2012, at 8:27 PM, Richard O'Keefe wrote:

...

On 20/02/2012, at 1:01 PM, Tom Murphy wrote:

...
Does anyone know what this will mean for the future of Haskell development in OS X?:

http://www.apple.com/macosx/mountain-lion/security.html

Quoting that document: Or you can install all apps from anywhere, just as you can today. You can even temporarily override your setting by Control-clicking, and install any app at any time. Gatekeeper leaves it all up to you.

So in the *short* term, it makes little difference.

...
1) Writing software for widespread use (a security setting is to only run software from the App Store, and I'd like to have my software function on users' computers.)

*Short* term, the most that will happen is that people will have to say "yeah yeah I know just let me have it OK?".

Already in 10.6 there was this nagging feature where you click on a downloaded document and it says "this was downloaded, do you really want to open it" and it takes a painfully long time bouncing in the dock before that dialogue box comes up.

Heck, I have to provide an administrator account & password when I want to run GDB in my own directory on my own program. (And you have to love the way they removed the MacOS equivalent of truss because it was superceded by DTrace, but you have to be superuser to use DTrace...)

*Short* term, it's just more continuing low-level harassment by Apple (even if perhaps with good intentions). Long term, well, there's a reason why I keep Solaris, Linux, and OpenBSD around...

_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe

Richard O'Keefe

11:27 p.m.

On 20/02/2012, at 3:04 PM, Jack Henahan wrote:

...

What's your setup like that you can't even use gdb in your own directory? That sounds unusual. And you can turn off the warning, either globally or selectively.[3][4]

My setup is Mac OS X 10.6.8, pretty much out of the box, plus a bunch of additional stuff, but nothing removed. The invariable University policy is that *nobody* except a few designated system administrators is allowed to have root access on any machine connected to the University's ethernets. (Apparently nobody has told them about VirtualBox yet, so I can happily root access Solaris, Linux, and OpenBSD on my Macs.) So - there's the root account, - there's an "admin" account just for me, which lets me turn the printer on and install software, but not run DTrace, and - there's my ordinary user account. I can run gdb just fine, it's setting a breakpoint and then trying to run the program that it doesn't like. I have to re-authenticate for this every time I log in.

...

[3]: http://osxdaily.com/2010/03/29/disable-the-are-you-sure-you-want-to-open-thi...

Thank you. I did not know about that. I have been working around it by deleting the com.apple.quarantine xattr.

...

[4]: http://osxdaily.com/2010/09/12/disable-application-downloaded-from-the-inter...

Now *that's* annoying. It turns out that the xattr command is *there*, but 'man xattr' is completely silent. There is nothing for it in /usr/share/man/man1 . I had been using my own command to do the equivalent of xattr -d.

Brandon Allbery

11:53 p.m.

On Sun, Feb 19, 2012 at 23:27, Richard O'Keefe wrote:

...

Now *that's* annoying. It turns out that the xattr command is *there*, but 'man xattr' is completely silent. There is nothing for it in /usr/share/man/man1 . I had been using my own command to do the equivalent of xattr -d.

Bzuh? haral:23276 Z$ pkgutil --file-info /usr/share/man/man1/xattr.1 volume: / path: /usr/share/man/man1/xattr.1 pkgid: com.apple.pkg.BSD pkg-version: 10.7.0.1.1.1293150744 install-time: 1310114676 uid: 0 gid: 0 mode: 644 (Lion, as you probably got from the pkg-version field, but I recall it also being on my SL desktop box that's currently in storage.) -- brandon s allbery allbery.b@gmail.com wandering unix systems administrator (available) (412) 475-9364 vm/sms

Richard O'Keefe

20 Feb 20 Feb

4:31 p.m.

On 20/02/2012, at 5:53 PM, Brandon Allbery wrote:

...

On Sun, Feb 19, 2012 at 23:27, Richard O'Keefe wrote: Now *that's* annoying. It turns out that the xattr command is *there*, but 'man xattr' is completely silent. There is nothing for it in /usr/share/man/man1 . I had been using my own command to do the equivalent of xattr -d.

Bzuh?

haral:23276 Z$ pkgutil --file-info /usr/share/man/man1/xattr.1 volume: / path: /usr/share/man/man1/xattr.1

pkgid: com.apple.pkg.BSD pkg-version: 10.7.0.1.1.1293150744 install-time: 1310114676 uid: 0 gid: 0 mode: 644

m% uname -a Darwin <deleted> 10.8.0 Darwin Kernel Version 10.8.0: Tue Jun 7 16:33:36 PDT 2011; root:xnu-1504.15.3~1/RELEASE_I386 i386 m% ls -l /usr/share/man/man1/xa* -rw-r--r-- 1 root wheel 5427 14 Jul 2009 /usr/share/man/man1/xar.1 -r--r--r-- 1 root wheel 3759 19 May 2009 /usr/share/man/man1/xargs.1.gz m% pkgutil --file-info /usr/share/man/man1/xattr.1 2012-02-21 10:25:36.201 pkgutil[7023:903] PackageKit: *** Missing bundle identifier: /Library/Receipts/NeoOffice-2.2.2-Intel.pkg 2012-02-21 10:25:36.222 pkgutil[7023:903] PackageKit: *** Missing bundle identifier: /Library/Receipts/NeoOffice-3.0.1-Intel.pkg volume: / path: /usr/share/man/man1/xattr.1 m% Since you are running Lion and I am not, it isn't _that_ surprising that we see different things. It remains surprising that in 10.6.8 the xattr command is there but its manual page is not. I've also checked a laptop running the same release of Mac OS X.

wren ng thornton

22 Feb 22 Feb

12:14 a.m.

On 2/20/12 4:31 PM, Richard O'Keefe wrote:

...

On 20/02/2012, at 5:53 PM, Brandon Allbery wrote:

...
Bzuh?

Since you are running Lion and I am not, it isn't _that_ surprising that we see different things. It remains surprising that in 10.6.8 the xattr command is there but its manual page is not.

The manpage is also missing on earlier versions (like my 10.5.8 laptop). Though usually for things like this you can just pass -? and either (1) it'll be recognized so a help message will be displayed, or (2) it won't be recognized and hence a help message will be displayed. Passing -? is safer than trying to run the program with no options, since many programs will do stuff even without options/arguments. -- Live well, ~wren

Tom Murphy

19 Feb 19 Feb

9:39 p.m.

...

*Short* term, the most that will happen is that people will have to say "yeah yeah I know just let me have it OK?".

Already in 10.6 there was this nagging feature where you click on a downloaded document and it says "this was downloaded, do you really want to open it" and it takes a painfully long time bouncing in the dock before that dialogue box comes up.

I disagree. I don't think the control-click bypass is realistic for real world applications. (Meaning software written for "the average user"). With the 10.6 dialogue box, it's clear that there's no negative inference about the particular software downloaded. On the other hand, it's impossible for a software company to maintain a sense of professionalism, when a user has to know a weird "secret handshake" to disable what they may perceive as equivalent to antivirus software.

...

*Short* term, it's just more continuing low-level harassment by Apple (even if perhaps with good intentions). Long term, well, there's a reason why I keep Solaris, Linux, and OpenBSD around...

I disagree that this is a small move. $100 per year from every Mac OS X developer in the world, plus 30% of the take from the App Store is big money. - amindfv / Tom

Austin Seipp

10:28 p.m.

On Sun, Feb 19, 2012 at 8:39 PM, Tom Murphy wrote:

...

On the other hand, it's impossible for a software company to maintain a sense of professionalism, when a user has to know a weird "secret handshake" to disable what they may perceive as equivalent to antivirus software.

I'll also just add that if you're an actual software company, large or small, the $100 for the developer ID, certificate, ability to do iOS/App store apps, whatever, is a business expense, that is utterly dominated by a million other factors, as developing high quality applications isn't exactly cheap, and the price of a license is really the last thing you're going to worry about. If you're more worried about the potential to impact individual developers and small open source teams who want to get their work out there, you are right it's a concern. We'll have to wait and see when more details arise. -- Regards, Austin

Manuel M T Chakravarty

21 Feb 21 Feb

3:52 a.m.

Austin Seipp:

...

On Sun, Feb 19, 2012 at 8:39 PM, Tom Murphy wrote:

...
On the other hand, it's impossible for a software company to maintain a sense of professionalism, when a user has to know a weird "secret handshake" to disable what they may perceive as equivalent to antivirus software.

I'll also just add that if you're an actual software company, large or small, the $100 for the developer ID, certificate, ability to do iOS/App store apps, whatever, is a business expense, that is utterly dominated by a million other factors, as developing high quality applications isn't exactly cheap, and the price of a license is really the last thing you're going to worry about.

If you're more worried about the potential to impact individual developers and small open source teams who want to get their work out there, you are right it's a concern.

I think, Apple has made their stance quite clear by releasing the command line dev tools: http://kennethreitz.com/xcode-gcc-and-homebrew.html Manuel

Stefan Monnier

22 Feb 22 Feb

10:14 a.m.

...

I think, Apple has made their stance quite clear by releasing the command line dev tools:

I'm not sure what you mean by that, but looking at the history of Apple devices, especially the recent history with iPad, iPhone, etc... it's pretty clear to me where this is headed: keep as tight a control on the machine as possible without alienating too many users. As time passes, the average users become accustomed to the idea that they shouldn't actually control their own device, which allows tightening the control yet a bit more. Cryptography and formal methods will eventually make it provably difficult to use your own device in any way other than the one Apple intended. Stefan PS: Of course, Apple is not the only company aiming for that, it's just the one leading the way.

Manuel M T Chakravarty

9 p.m.

Stefan Monnier:

...

...
I think, Apple has made their stance quite clear by releasing the command line dev tools:

I'm not sure what you mean by that, but looking at the history of Apple devices, especially the recent history with iPad, iPhone, etc... it's pretty clear to me where this is headed: keep as tight a control on the machine as possible without alienating too many users.

It means that Apple likes to accommodate devs who prefer a traditional Unix environment over using IDEs (such as Xcode) and devs that use alternative tool chains (such as GHC). Manuel

Austin Seipp

12:49 p.m.

Manuel, Thanks for the references and follow up. I had seen Kennith's posts about the new command line tools for XCode, but didn't seen John Gruber's take! Much appreciated. On Tue, Feb 21, 2012 at 2:52 AM, Manuel M T Chakravarty wrote:

...

Austin Seipp:

...
On Sun, Feb 19, 2012 at 8:39 PM, Tom Murphy wrote:

...
On the other hand, it's impossible for a software company to maintain a sense of professionalism, when a user has to know a weird "secret handshake" to disable what they may perceive as equivalent to antivirus software.

I'll also just add that if you're an actual software company, large or small, the $100 for the developer ID, certificate, ability to do iOS/App store apps, whatever, is a business expense, that is utterly dominated by a million other factors, as developing high quality applications isn't exactly cheap, and the price of a license is really the last thing you're going to worry about.

If you're more worried about the potential to impact individual developers and small open source teams who want to get their work out there, you are right it's a concern.

I think, Apple has made their stance quite clear by releasing the command line dev tools:

http://kennethreitz.com/xcode-gcc-and-homebrew.html

Manuel

-- Regards, Austin

4837

Age (days ago)

4840

Last active (days ago)

List overview

Download

19 comments

8 participants

participants (8)

Austin Seipp
Brandon Allbery
Jack Henahan
Manuel M T Chakravarty
Richard O'Keefe
Stefan Monnier
Tom Murphy
wren ng thornton