Offer Java-less OS X .app bundle

[GoogleCodeExporter]

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 soylentm...@gmail.com on 17 Mar 2015 at 9:13

Attachments:

• JavaAppLauncher

[GoogleCodeExporter]

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 comment by psii...@gmail.com on 18 Mar 2015 at 10:26

[GoogleCodeExporter]

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 comment by soylentm...@gmail.com on 18 Mar 2015 at 12:26

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

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 comment by soylentm...@gmail.com on 18 Mar 2015 at 12:41

[GoogleCodeExporter]

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 comment by psii...@gmail.com on 18 Mar 2015 at 12:42

[GoogleCodeExporter]

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

Original comment by psii...@gmail.com on 18 Mar 2015 at 12:45

[GoogleCodeExporter]

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 comment by soylentm...@gmail.com on 18 Mar 2015 at 1:12

[GoogleCodeExporter]

Thanks!

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

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

Original comment by psii...@gmail.com on 18 Mar 2015 at 1:18

[GoogleCodeExporter]

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

Original comment by psii...@gmail.com on 18 Mar 2015 at 1:20

[GoogleCodeExporter]

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 comment by soylentm...@gmail.com on 18 Mar 2015 at 1:55

[GoogleCodeExporter]

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 comment by psii...@gmail.com on 18 Mar 2015 at 1:59

• Changed state: Accepted

[GoogleCodeExporter]

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 comment by soylentm...@gmail.com on 18 Mar 2015 at 3:33

[GoogleCodeExporter]

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 comment by soylentm...@gmail.com on 19 Mar 2015 at 12:48

Attachments:

• zap.sh.patch

[GoogleCodeExporter]

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#getMenuShortcutK
eyMask%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 comment by soylentm...@gmail.com on 19 Mar 2015 at 3:54

Attachments:

• osx-look-keymask.patch

[GoogleCodeExporter]

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 comment by psii...@gmail.com on 19 Mar 2015 at 4:00

[GoogleCodeExporter]

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 comment by soylentm...@gmail.com on 19 Mar 2015 at 4:45

[GoogleCodeExporter]

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 comment by soylentm...@gmail.com on 19 Mar 2015 at 8:22

[GoogleCodeExporter]

Will do!

Original comment by psii...@gmail.com on 20 Mar 2015 at 11:30

[GoogleCodeExporter]

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 comment by psii...@gmail.com on 20 Mar 2015 at 12:56

[GoogleCodeExporter]

I guess "April King" is fine.  :P

Original comment by soylentm...@gmail.com on 20 Mar 2015 at 4:43

[GoogleCodeExporter]

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 comment by THC...@gmail.com on 20 Mar 2015 at 7:01

[GoogleCodeExporter]

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 comment by soylentm...@gmail.com on 20 Mar 2015 at 7:12

[GoogleCodeExporter]

Thanks!

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

Original comment by THC...@gmail.com on 20 Mar 2015 at 7:51

[GoogleCodeExporter]

ZAP has been migrated to github

This issue will be on github issues with the same ID: 
https://github.com/zaproxy/zaproxy/issues

Original comment by psii...@gmail.com on 5 Jun 2015 at 9:18

• Changed state: Done