Applets and 1.7.0_21?

[Knute Johnson]

I've got some software running in the wild that uses JApplets. My
client decided to update the Java version from 1.6 something to
1.7.0_21. The applets communicate with the server they come from. This
caused a security exception. I re-compiled and self-signed one of the
applets to see if that would solve the issue but then I got a
ConnectException. I'm not sure why and it could be related to the
Serialzed data being transmitted between the applet and server.

Should self signing the .jar files solve any problems from changing the
Java versions for my applets?

Thanks,

--

Knute Johnson

[Knute Johnson]

I just found this on the Oracle site;

"Changes to Java Control Panel's Security Settings

In this release, low and custom settings are removed from the Java
Control Panel(JCP)'s Security Slider.

Depending on the security level set in the Java Control Panel and the
user's version of the JRE, self-signed or unsigned applications might
not be allowed to run. The default setting of High permits all but local
applets to run on a secure JRE. If the user is running an insecure JRE,
only applications that are signed with a certificate issued by a
recognized certificate authority are allowed to run."

What do they mean by a secure JRE?

--

Knute Johnson

[Arne Vajhøj]

On 5/21/2013 11:58 AM, Knute Johnson wrote:
> On 5/21/2013 8:45 AM, Knute Johnson wrote:
>> I've got some software running in the wild that uses JApplets. My
>> client decided to update the Java version from 1.6 something to
>> 1.7.0_21. The applets communicate with the server they come from. This
>> caused a security exception. I re-compiled and self-signed one of the
>> applets to see if that would solve the issue but then I got a
>> ConnectException. I'm not sure why and it could be related to the
>> Serialzed data being transmitted between the applet and server.
>>
>> Should self signing the .jar files solve any problems from changing the
>> Java versions for my applets?
>

> I just found this on the Oracle site;
>
> "Changes to Java Control Panel's Security Settings
>
> In this release, low and custom settings are removed from the Java
> Control Panel(JCP)'s Security Slider.
>
> Depending on the security level set in the Java Control Panel and the
> user's version of the JRE, self-signed or unsigned applications might
> not be allowed to run. The default setting of High permits all but local
> applets to run on a secure JRE. If the user is running an insecure JRE,
> only applications that are signed with a certificate issued by a
> recognized certificate authority are allowed to run."
>
> What do they mean by a secure JRE?

I think they mean:

insecure = old with known vulnerabilities

secure = no known vulnerabilities

And with recent history secure approx. means latest.

Arne

[markspace]

On 5/21/2013 9:15 AM, Arne Vajh�j wrote:

> insecure = old with known vulnerabilities
>
> secure = no known vulnerabilities

I haven't read it but I'd guess that "secure" might also refer to a
sandboxed app, one run with a defined set of security restrictions.

[Arne Vajhøj]

That is the normal distinction.

But in this context I doubt it is the case.

Arne

[Richard Maher]

I have an unsigned applet that talks back to the codebase through
sockets and does not have any problems.

Were you signed or unsigned before or a mix?

Does this help:-
http://www.oracle.com/technetwork/java/javase/tech/java-code-signing-1915323.html

Cheers Richard Maher

[Knute Johnson]

The applets were running unsigned. I just tried to see if I could solve
the problems by signing one. It wasn't that successful.

I think what we are going to do is to convert their code to an
application. That's what I wanted to do from the get go but they were
convinced that this would be less hassle. I'm not sure they are
convinced any more :-).

--

Knute Johnson

[Qu0ll]

"Knute Johnson" wrote in message news:kng4jh$pcm$1...@dont-email.me...

Reply at the end...

-------------------------

------------------------

I know of some applets and Web Start apps that either will not launch at all
or have serious problems since upgrading to 7u21. In many of these cases
there is no obvious way to get things to work again and certainly signing is
not the solution.

It appears Oracle did not properly consider all the possible implications of
the new "secure" plugin on production apps/applets and do not always have an
effective work-around.

--
And loving it,

-Qu0ll (Rare, not extinct)
_________________________________________________
Qu0llS...@gmail.com
[Replace the "SixFour" with numbers to email me]

[John B. Matthews]

In article <knh41p$akt$1...@dont-email.me>,

You may be able to preserve your options by moving toward a hybrid
applet/application deployed via Java Web Start; some related
examples are cited here:

<http://stackoverflow.com/q/12449889/230513>

--
John B. Matthews
trashgod at gmail dot com
<http://sites.google.com/site/drjohnbmatthews>

[Knute Johnson]

On 5/22/2013 11:43, John B. Matthews wrote:
> In article <knh41p$akt$1...@dont-email.me>,
> Knute Johnson <nos...@knutejohnson.com> wrote:
>
>> I think what we are going to do is to convert their code to an
>> application. That's what I wanted to do from the get go but they
>> were convinced that this would be less hassle. I'm not sure they
>> are convinced any more :-).
>
> You may be able to preserve your options by moving toward a hybrid
> applet/application deployed via Java Web Start; some related
> examples are cited here:
>
> <http://stackoverflow.com/q/12449889/230513>
>

Thanks for that article John. The whole project was a series of four
JApplets and some HTML code. I've converted the applets to JFrame
applications which really only required minor changes to the code.
Mostly finding all the AppletContext calls to reload the browser and
replacing them with JFrame.dispose(). Then I wrote a menu application
that calls those apps and some Desktop.browser calls for the remaining
HTML that they needed access to. It is a little cludgy but no more so
than the applets were to begin with. It actually gives them slightly
more utility as they can have all four applications open at once in
separate JFrames.

I don't think running them as Java Web Start applications will work any
differently with the new security requirements than the applets did.
It's also not clear to me that self-signing is going to be adequate either.

I did find one interesting bug in some old code where I didn't dispose
of the Dialog that was used with a JFileChooser. It was preventing one
of the apps from stopping completely. The only reason that I can think
of that that didn't cause them problems before was that they didn't run
that piece of code very often (so no out of memory error) and it was
hidden by the browser.

Thanks,

knute...