Offer Java-less OS X .app bundle

[zapbot]

Given that many Macbooks (including my own) come with a relatively small SSD, it would
be great to offer a Java-less version of the OS X install that still comes as an .app
bundle.

It should be pretty easy during the build process:

1) Replace JavaAppLauncher with the attached shell script, and
2) Delete Contents/PlugIns  (which contains the old JDK)

It should save ~112MB and still work like the standard OS X bundle, while requiring
no changes to Info.plist or any of the other bits.

Original issue reported on code.google.com by soylentmean on 2015-03-17 21:13:50

---

• Attachment: JavaAppLauncher

[zapbot]

On the downloads page https://code.google.com/p/zaproxy/wiki/Downloads it states:

"The Mac OS version includes Java 7 - you can use the 'Linux / cross platform' version
if you do not want to download this."

The Linux / Cross platform version includes the standard zap.sh script which works
on OS X.
Is this not the same thing?

Original issue reported on code.google.com by psiinon on 2015-03-18 10:26:35

[zapbot]

Well, it's the same scripts and bundle of files, but Finder (as well as Path Finder)
don't execute zap.sh when double-clicked; as such, the cross-platform version requires
you to open up a Terminal and manually execute it every time you want to run it.

The OS X version currently available is an app bundle that you can simply drag into
your Applications folder and execute like any other native OS X application.  It's
just very large, due to the forced inclusion of a (year old) version of Java.

Original issue reported on code.google.com by soylentmean on 2015-03-18 12:26:10

[zapbot]

Also, I realized that the native version uses the OS X status bar at the top, which
zap.sh (the cross-platform version), and the stripped out version (attached) don't
use.  Give me a bit and I'll see if I can get a JavaAppLauncher replacement that does.

Note that issue 1162 is a bit of a related issue, as the user is assuming that zap.sh
behaves like running ZAP normally.  Clicking on OWASP ZAP.app, however, executes JavaAppLauncher,
which sets up the environment and then run Java against zap.jar directory.

Original issue reported on code.google.com by soylentmean on 2015-03-18 12:41:29

[zapbot]

That would be great :)
TBH I'd rather just provide a java-less Mac OS bundle, but other people have told me
that not what most Mac users will accept.
Do you think we need both or could we get away with the java-less one?

btw I've tried updating to the most recent version of Java, but it fails for me :(
No doubt I'm doing something wrong - I'm not a Max expert by any means.
Help with that (if you think we need it) would also be great ;)

Original issue reported on code.google.com by psiinon on 2015-03-18 12:42:34

[zapbot]

Of course you are in danger of becoming the official ZAP Mac OS package maintainer ;)

Original issue reported on code.google.com by psiinon on 2015-03-18 12:45:42

[zapbot]

I'll have you know that I've been a good person, and that I in no way deserve such a
horrible fate!  :P

I sympathize with those that want Java bundled into the application.  Java is in pretty
rough shape on OS X: Apple has generally refused to update past Java 6.  Oracle isn't
making it any better, because unlike on Windows/Linux, where the JRE comes with their
browser plugin, on OS X, it's a browser plugin that has the JRE bundled inside.  IIRC,
updating this plugin (which is what you get when you search for "java os x") doesn't
update the java that runs out of /usr/bin/java.  Installing the JDK *does* replace
the system java.  Both of them are now subject to the ask.com toolbar scourge.  Ugh.

And then you also have whackjobs like myself that have so horribly mangled their system
with repeated Java installs so that their systems are unrecognizable horror shows.

Getting out of the bundling Java business does sound like a good idea, but I think
it will require some cleverness to make the whole thing work such that it doesn't require
users to install the full JDK.  Let me think on it, and get back to you.

Original issue reported on code.google.com by soylentmean on 2015-03-18 13:12:26

[zapbot]

Thanks!

There is this: http://docs.oracle.com/javase/7/docs/technotes/guides/jweb/packagingAppsForMac.html

Or we could look at bundling OpenJDK?
We'd have to be very careful about licensing with that though :/

Original issue reported on code.google.com by psiinon on 2015-03-18 13:18:23

[zapbot]

https://wikis.oracle.com/display/OpenJDK/How+to+embed+a+.jre+bundle+in+your+Mac+app

Original issue reported on code.google.com by psiinon on 2015-03-18 13:20:09

[zapbot]

It was my (very vague) understanding that you can bundle OpenJDK alongside applications,
just like the Oracle JRE, without getting entangled into a licensing nightmare.  But
I'm definitely not a lawyer, and if I were you, I'd probably start denying you ever
engaged in this thread.  :P

Anyways, I'll start with fixing zap.sh, which behaves very badly on OS X.  Then maybe
I'll look into bundling.  :)

The main benefit of bundling the JRE is that you can sign it, and then you can ship
it on the App Store.  The App Store, whatever, but having it signed would be great.
 Having to manually allow execution with each new version is kind of a pain.  But I
don't know if you or the other project leads have an apple code signing cert for this
purpose?

Original issue reported on code.google.com by soylentmean on 2015-03-18 13:55:41

[zapbot]

What thread? I dont know about any OpenJDK licensing thread! :P

TBH I'd just like ZAP to run nicely on Mac OS ;)
Getting onto the App store would be a nice-to-have, but its definitely not a priority
for me right now.
Done know about an apple code signing cert, but we might be able to get a generic OWASP
one if that would really help.

Original issue reported on code.google.com by psiinon on 2015-03-18 13:59:35

[zapbot]

Hey, me too!  Anyways, I've got a small patch to zap.sh which at least makes the OS
X version look a bit better.  Would you rather I just attach the patch, or are you
willing to make me a committer?  I'm okay either way.  :)

Original issue reported on code.google.com by soylentmean on 2015-03-18 15:33:19

[zapbot]

So, I've attached a patch file to the very standard zap.sh file.  While it does make
things a good deal more usable, I will say that there are a number of issues involved:

1) the cross-platform version doesn't include, for example, properly handle the dock†,
creating a dock icon of "java", without the proper iconography (which doesn't actually
come with the cross-platform version)

2) this patch probably should realistically take place in the build system, setting
it as a System.property in src/org/zaproxy/zap/ZAP.java -> run()

3) doesn't fix the problem with all of the standard OS X handlers (see issue 1570)

† To be fair, a lot of that is the result of Apple/Oracle neglecting OS X, and failing
to fix a multi-year-old bug at this point; I don't know if any amount of command-line
gimmickery (which should honestly be fine) can substitute for an application that uses
a native shim, lots of ifdefs, and properly implemented handlers

Original issue reported on code.google.com by soylentmean on 2015-03-19 00:48:44

---

• Attachment: zap.sh.patch

[zapbot]

Okay, was a little less awful getting everything into Eclipse than I'd thought it would
be.  <_<  >_>  <_<

It should fix two issues:
1) Lack of OS X menubar when running without the shim  (this is now set in run())
2) Lack of proper keyboard shortcuts on OS X

Looking through the code, it seems that there were a couple of different ways that
people set the key masks (ie, CTRL_MASK) in the code:

Event.CTRL_MASK, or java.awt.Event.CTRL_MASK

Either way, neither is the proper way to set the keymask in a platform independent
way.  See:
https://docs.oracle.com/javase/7/docs/api/java/awt/Toolkit.html#getMenuShortcutKeyMask%28%29

Anyways, they've all been updated to use Toolkit.getDefaultToolkit().getMenuShortcutKeyMask().
 Any file that didn't have java.awt.Toolkit in their namespace have been modified to
have it there.

Original issue reported on code.google.com by soylentmean on 2015-03-19 15:54:13

---

• Attachment: osx-look-keymask.patch

[zapbot]

Minor suggestion re zap.sh
Test for "$OS" = "Darwin" and let an else path handle everything else, just in case
some systems dont retur n"Linux" (eg maybe Kali?)
Other than that they are all good to go.
You should have commit perms now - can you apply you fixes to the zaproxy trunk, 2.4
branch and the zap-extensions project?
Many thanks!

Original issue reported on code.google.com by psiinon on 2015-03-19 16:00:14

[zapbot]

I left the conditionals as they were, since they had presumably been working up to this
point.  :)

I can change it to be as you requested, but it will generate an error on any system
where someone might run the bash script but where they don't have /proc (*BSD, Cygwin,
etc.)  Also, fwiw:

$ uname -s
Linux

$ cat /etc/issue
Kali GNU/Linux 1.1.0 on \n \l

So no worries there.  :)

Original issue reported on code.google.com by soylentmean on 2015-03-19 16:45:47

[zapbot]

Hey, @psiinon?  Could you take a look at the commits and make sure that everything looks
okay?  Don't want to completely screw things up on my first set of commits.  :)

Thanks!

Original issue reported on code.google.com by soylentmean on 2015-03-19 20:22:47

[zapbot]

Will do!

Original issue reported on code.google.com by psiinon on 2015-03-20 11:30:14

[zapbot]

I've tried it on Linux and a Mac mini and it all seems good :)
How would you like to be credited? 
https://code.google.com/p/zaproxy/wiki/HelpCredits

Many thanks!

Original issue reported on code.google.com by psiinon on 2015-03-20 12:56:33

[zapbot]

I guess "April King" is fine.  :P

Original issue reported on code.google.com by soylentmean on 2015-03-20 16:43:51

[zapbot]

The above changes (i.e. use of Toolkit.getMenuShortcutKeyMask()) were not done in alpha
and beta branches of zap-extensions project.
Would you mind do the changes in those branches too?

Original issue reported on code.google.com by THC202 on 2015-03-20 19:01:29

[zapbot]

Sure, that shouldn't be a problem.  This is my first time using Subclipse: is there
any way to commit to multiple branches (alpha, beta, and trunk) all at the same time,
or do you basically have commit to a branch, switch, commit/merge, switch, commit/merge
(or just checkout all three different versions into the workspace?)

Original issue reported on code.google.com by soylentmean on 2015-03-20 19:12:49

[zapbot]

Thanks!

Yes, just switch to root of the repo, you can then change/commit all the branches/trunk
at the same time.

Original issue reported on code.google.com by THC202 on 2015-03-20 19:51:38

[aaronweaver]

I'd like to bump the request for code signing on the mac. That's a task I could take if you like.

[psiinon]

@aaronweaver : go for it :) Would we just need to get a suitable code signing cert (once you've made the relevant changes)? Hopefully this is one we could reuse for other platforms, like Windows?