Plugin Support

[AliSoftware]

Discuss how we would handle cocoapods-plugins in the bundled App. /cc @alloy

Should we have a menu that list all known plugins (probably fetched from the plugins.json file) and allows the use to install them for the bundled cocoapods in one click?

---

Maybe we should also only embed SCM tools only if the corresponding cocoapods-plugin is installed, namely don't embed bazaar, hg or svn binaries in the initial .app, and only download a bundled svn.tar.xz containing the SVN binary when the use choose to install the cocoapods-svn plugin?
(This solution would lighten the CocoaPods.app package a lot)

[alloy]

I think we should have a 'pod plugins install cvs' command which runs 'gem install cocoapods-cvs and bundle that with the app bundle. Care to add that to the plugins plugin? :)

[alloy]

Regarding SCM, we should bundle all that cocoapods-downloader supports. This is unrelated to hosting your spec repo in another SCM. It should just work out of the box, that's the point of the app bundle.

[alloy]

As far as exposing more things in the UI goes, that's outside of the scope of the first release. The first release is about a full featured CLI installation of CP.

[AliSoftware]

I think we should have a 'pod plugins install cvs' command which runs 'gem install cocoapods-cvs and bundle that with the app bundle. Care to add that to the plugins plugin? :)

I may add a pod plugins install name command to the cocoapods-plugins plugin that runs gem install cocoapods-name, sure. Not sure that's worth it, but I can do it.
But why should that command automatically bundle it with the app bundle? I mean, what if the user don't use the CocoaPods.app bundle but instead installed CP with gem install cocoapods — like we all do for now — and still wants to pod plugins install someplugin?

Besides, I haven't had time to look on CocoaPods.app yet so not sure how one would "bundle a gem into the app bundle" or what is meant by that (app bundles being code-signed on OSX, we can't add stuff to the bundle afterwards)

[segiddins]

The issue with a plugins command to install a plugin is what if the gem is coming from a Gemfile?

[alloy]

I don’t think we need to expose the pod plugins install NAME command outside of the context of the CocoaPods.app context. It would make little sense, because the user is clearly already familiar with gem install.

The reason we need it for CocoaPods.app is because we have only 1 bin that we expose outside of the application bundle, which is pod. So to install a gem you would need to know the path to the gem command inside the application bundle, which is not really user-friendly.

[alloy]

app bundles being code-signed on OSX, we can't add stuff to the bundle afterwards

Hmm, this is a good question. Does it really not allow addition of files to the bundle?

[segiddins]

Ah, I was thinking of exposing a GUI inside the app for plugin installation, ala Alcatraz.

-Samuel E. Giddins

On Nov 23, 2014, at 12:24 PM, Eloy Durán notifications@github.com wrote:

I don’t think we need to expose the pod plugins install NAME command outside of the context of the CocoaPods.app context. It would make little sense, because the user is clearly already familiar with gem install.

The reason we need it for CocoaPods.app is because we have only 1 bin that we expose outside of the application bundle, which is pod. So to install a gem you would need to know the path to the gem command inside the application bundle, which is not really user-friendly.

—
Reply to this email directly or view it on GitHub.

[AliSoftware]

Does it really not allow addition of files to the bundle?

Never tried it myself (I stopped developing OSX apps and went to iOS apps before CodeSigning was introduced on OS X) but I would be strongly surprised that it does allow it, because changing he content of the bundle means changing the signature of the whole bundle, thus making the CodeSigning invalid, right?
(Otherwise the CodeSigning would be pointless if anyone can modify an app bundle and transform the app into a Trojan)

[alloy]

I’ve updated the README to clarify the design goals better. I hope that helps, in terms of prioritising things like UI additions.

[alloy]

(Otherwise the CodeSigning would be pointless if anyone can modify an app bundle and transform the app into a Trojan)

@AliSoftware That’s not true. The signature could verify that files existing at the time of signing are unchanged. Added files do not automatically get executed.

Nonetheless, I have never looked into those details :)

@samdmarshall Would you know?

[AliSoftware]

Good point. Besides, I just realized that Xcode.app itself does add files to its bundle… when we download additional iOS Simulators for example!

Still need some more information about all that to understand it better.

Still, I'm not sure to know how the pod executable would find other gems (like plugins) in the right place, does it have kinda like its own $GEM_HOME or something? (not a rubyist enough to know all the subtleties)

[alloy]

when we download additional iOS Simulators for example!

Doh! Good point :D

Still, I'm not sure to know how the pod executable would find other gems (like plugins) in the right place, does it have kinda like its own $GEM_HOME or something? (not a rubyist enough to know all the subtleties)

Yup. When running gem from inside the app bundle it should all work as you’d expect. The only thin you need to worry about is whether or not the user has write access to $GEM_HOME and if not, perform the command with sudo instead.

[AliSoftware]

You mean that the $GEM_HOME used by the bundled ruby distribution inside CocoaPods.app would obviously be different from the system's Ruby's $GEM_HOME, so that /CocoaPods.app/Contents/gem install x will automatically install the gem x inside the CocoaPods.app/Contents/gems/ directory or similar, while /usr/bin/gem install x will install the gem x in /Library/Ruby/Gems/2.0.0/gems/, right?

It's been ages since I have developed for OS X, but as far as I know, running commands that needs sudo access are not so trivial… as in order to do it right and avoid security risks and privilege escalation, one need to do specific stuff, like do the work in a dedicated service separated from the main app executable, etc…
Never done such stuff, but if we want to do it, we will have to be careful with security and privileges, and that won't be as simple as invoking an NSTask.

[AliSoftware]

For reference I just found Apple's SMJobBless Sample code on privilege escalation.

This confirms that to do it properly, we need a helper that will be installed as a LaunchDaemon or PrivilegedHelperTool, bless it using methods from <Security/Authorization.h> + provide an IPC architecture to make the app & helper talk to each other + use XPC to talk to that helper.

[alloy]

@AliSoftware No that’s only needed if this were about doing this from the UI, which is not the case, this is purely about CLI usage.

I tried to make it clear in the README, but maybe it’s still not clear enough; the only thing we need right now is to be able to do the following from Terminal.app (or whatever your terminal app of choice is):

$ pod-binstub install plugins roulette

If the user does not have write access to the $GEM_HOME which resides inside the CocoaPods.app bundle, then they should see:

Installing the plugin to your CocoaPods installation requires escalated privileges to
write to `/Applications/CocoaPods.app/Contents/Resources/bundle/lib/ruby/gems/2.1.0/gems`.
password:

Afterwards, or if the user has write access, they should see:

Fetching: cocoapods-roulette-1.0.2.gem (100%)
Successfully installed cocoapods-roulette-1.0.2
Parsing documentation for cocoapods-roulette-1.0.2
Installing ri documentation for cocoapods-roulette-1.0.2
Done installing documentation for cocoapods-roulette after 0 seconds
1 gem installed

[alloy]

And to be clear, pod-binstub is a tool that ends up doing something like:

$ pod-binstub --help

$ /Applications/CocoaPods.app/Contents/Resources/bundle/bin/bundle-env pod --help

[neonichu]

Regarding code-signing, there's a plist Contents/_CodeSignature/CodeResources in the bundle which lists individual files and their signatures. So adding additional files is generally fine.

[alloy]

I’ve moved this to #28 which has a clean list of requirements.