@orta => Move to pre-install hook #31
Conversation
|
OK, so after talking with @alloy about this, I've got a plan of attack:
CocoaPods should then install the keys as a normal pod. The other great idea (from @mrackwitz) was to force the use of static libraries instead of frameworks (to make the keys more obfuscated, in the main binary). I'm going to go with just what's above first, since we need to get Eidolon in a shipping state. Later, we can worry about improving on that process. @orta Make sense to you? @anyone Any gotchas I should be aware of? |
|
looks legit |
|
OK, so this obviously needs cleanup, but as a proof-of-concept, I think it's ready to be reviewed. Here's how it works:
I have one concern over this strategy: the podspec and the pod name need to be the same, but I'm downloaded the podspec remotely so I can't rename it at runtime (at least, I haven't tried that hard yet). That means that the module containing the keys will always been called |
lib/plugin.rb
Outdated
There was a problem hiding this comment.
Do I even need this (now empty) module?
|
Just verified that this runs OK on a device (once you remove Hockey's reference to |
lib/pod/command/keys/generate.rb
Outdated
There was a problem hiding this comment.
This can be done a bit simpler:
File.write(interface_file, key_master.interface)There was a problem hiding this comment.
Cool – I had copied over some (more complex) code from another of this plugin's files and modified it. Makes sense there'd be an easier way.
|
Addressed feedback and cleans up some concerns I noted earlier. |
lib/plugin.rb
Outdated
There was a problem hiding this comment.
what was the motivation for the command?
There was a problem hiding this comment.
It is used by the prepare_command in the podspec to generate the .h/.m files in the pod's directory.
|
This looks and feels great. And to triple clarify, this work fine with static lib only pods? |
|
Can you clarify what you mean? The generated pod doesn't specify to use frameworks or not, so it should work with non-frameworks pods. I'll verify. |
|
Coo |
|
Verified that this works on installations without frameworks: https://github.com/ashfurrow/static-keys-test (checked in Pods folder). @orta to quadruple clarify, these changes have not implemented Marius' suggestion to force the pod to be a framework (and thus integrated into the app's binary, further obfuscating the key values). I thought this solution was a reasonable for now (mostly to ship Eidolon) and I could come back and improve it later. |
So obviously this is pretty bare right now, but it's kind of a proof-of-concept. Was excited to dig into this after a day of walking about Newcastle yesterday, but someone nerd-sniped me with TV Tropes. I'll be submitting little chunks of work as I get them.
I've looked through the CocoaPods codebase (Rainforest is awesome) and am pretty sure that I want to inject my new, faked podspec in the
Installerclass'install!method, which I've monkey patched here (including a call to the original). This makes sense as a place for pre-install hooks.I'm still experiencing intermittent installation failures when I call through to the original method. This cafe's wifi is not great, so I'm unable to troubleshoot further (and momentarily getting on a ferry sans Internet). I think it's wise for me to figure out what that's all about before moving on with further monkeys' patches.