Closed GoogleCodeExporter closed 9 years ago
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
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
[deleted comment]
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
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
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
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
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
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
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
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
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
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:
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:
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
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
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
Will do!
Original comment by psii...@gmail.com
on 20 Mar 2015 at 11:30
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
I guess "April King" is fine. :P
Original comment by soylentm...@gmail.com
on 20 Mar 2015 at 4:43
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
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
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
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
Original issue reported on code.google.com by
soylentm...@gmail.com
on 17 Mar 2015 at 9:13Attachments: