This content has been marked as final. Show 12 replies
>Why are you even including jhall.jar in a webstart deployment? Does this application actually generate help sets?
It's the jhall.jar file in the JavaHelp distribution.>
The reason I ask is that I did some work on [webstart deployment of JavaHelp|http://pscode.org/jh/] and concluded that jhall.jar was not required for any webstart launch where the app. simply used JavaHelp to display help*. Furthermore, there are types of JavaHelp deployment that can be sandboxed.
* See comment on the [security constraints page|http://pscode.org/jh/security.html].
"Access 'unsafe' properties (e.g. user.dir/user.home). This seems to apply only to jhall.jar, which is used by a variety of CLI based applications."
Whatever you do you must include jhall or jh or jhbasic and they're all signed by the same (expired) certificate.
I've checked the all trust chain hoping some VeriSign had expired, they're not (the next expiring one is the Intermediate certificate, Class 3 Code Signing, the one the Sun certificate is released by, and it's expiring in 2014).
The best I can tell is VeriSign is changing all intermediate certificates (moving to 1024 bith) on May 17th, so maybe Sun is just waiting for the new Intermediate instead of renewing from the old one.
No news (or certificates) available on sun's site (ASAICT).
God point is just one JH's View needs all-permissions, so you don't need them, unless you're using bookmarks or whatever that View's name is, I don't remember exactly cause we took it away ages ago, but kept all-permissions 'till yesterday, now we're happily running without it in all are test environments and we should be promoting to production in a couple of days.
Is there any news on this? This is a serious breach of faith with everyone who has developed WebStart apps that use JavaHelp - no-one wants their customers seeing security warning dialogs when they try to execute an app.
It is astounding to me that Sun would allow this to happen, and even more amazing that there seems to be absolutely no effort to correct the situation or disseminate any relevant information.
>Well, if anyone from sun searched the JavaHelp issues for ['certificate expired'|https://javahelp.dev.java.net/issues/buglist.cgi?Submit+query=Submit+query&component=javahelp&subcomponent=www&issue_status=NEW&issue_status=STARTED&issue_status=REOPENED&version=current&email1=&emailtype1=exact&emailassigned_to1=1&email2=&emailtype2=exact&emailreporter2=1&issueidtype=include&issue_id=&changedin=&votes=&chfieldfrom=&chfieldto=Now&chfieldvalue=&short_desc=certificate+expired&short_desc_type=fulltext&long_desc=&long_desc_type=fulltext&issue_file_loc=&issue_file_loc_type=fulltext&status_whiteboard=&status_whiteboard_type=fulltext&field0-0-0=noop&type0-0-0=noop&value0-0-0=&cmdtype=doit&order=Issue+Number], they would probably be left with the impression that nobody cared.
It is astounding to me that Sun would allow this to happen, ...>
As for me, I would simply re-sign the Jar's with whatever certificate I was using for the main application, assuming that JavaHelp could not be delivered sandboxed (which it often can).
The main app isn't signed - it runs in the sandbox. The Help module needs to be signed because it has access to the printer.
It's a JOGL app. The JOGL binaries also began throwing security warnings a week or so ago when the cert expired (same cert, probably). The JOGL crew managed to get the distribution signature corrected and their binaries are no longer causing security warnings. The JavaHelp crew may want to get some pointers. And do something about this.
Sorry, I've read JavaHelp license over and over: it's explicitly told you can redistribute jars, but they must be exactly the same, signing changes them, it's not about 'compiled code', license lists out redistributable files. So you'd be going against it (I must confess I don't think Sun would sue anyone for this, but it doesn't change the matter).
Last suggestion to try solving te problem: have a look here . It's not so crucial to me to spend time dealing with the whole TSA problem (to see if JH is TSA signed or signable, which certificates should be imported, and so on), but, maybe, it is to you.
Edited by: Luca-Sanna on May 21, 2009 2:16 AM
So the license says that re-signing the jar is a violation?
If that's the case, then it is clearly Sun's responsibility to re-sign the distribution jars. They're hosing every customer who has built this into their apps. The silence from Sun is a strong indication that they don't take these responsibilities seriously. They're screwing their customers.
So is there any public interface with Sun where a complaint could be filed? Some way to light a fire under the appropriate ass? Or is this simply another dead technology, dropped by Sun without a word to the users?
I'm afraid I can't take Sun or Java seriously when they can't even manage basic administrative tasks without screwing up.
Looks like the javahelp binary containing the expired certificate is that one from sun.com site.
The jar files on the javahelp.dev are not signed and should be used instead.
Users can obtain that binary from : https://javahelp.dev.java.net/#binary
It may even be an idea to retire the http://java.sun.com/javase/technologies/desktop/javahelp/index.jsp
site given that the javahelp project is now hosted on the dev.java.net website.