Signing an applet

[emf]

I am trying to understand how to self-sign an applet. I've already
checked websites that provide directions, but unfortunately I realized
that my relevant knowledge is too limited to start understanding what
they are talking about, so I post here hoping I'll get some help to get
me started.

From what I've read so far I realized I needed JDK, so I've already
installed it. (BTW, I also use Eclipse.)

Now, in

http://www-personal.umich.edu/~lsiden/tutorials/signed-applet/signed-applet.html

under "How To Create a Signed Applet"

I believe I have completed step 1, as you can see in my webpage

https://files.nyu.edu/emf202/public/jv/nataltransits.html

So we come to step 2. It starts:

============
Create a public/private key pair. The command for this is

keytool -genkey
============

My initial question is: Where do I enter this command?

Alternatively, and probably even better, is there a webpage I have
missed that provides step by step instructions that an amateur java
programmer with my level of ignorance can understand?

Thanks,

emf

 

[Stefan Ram]

My initial question is: Where do I enter this command?

Into the text command prompt (sometimes called "shell") of
your operating system. Additional requirements might apply
such as having a command search path set up properly. This
is explained in the operating system literature, usually
separate from Java literature. A manual might already be
part of your operating system.

Alternatively, and probably even better, is there a webpage I have
missed that provides step by step instructions that an amateur java
programmer with my level of ignorance can understand?

Search for tutorials or text books about your operating systems,
especially text commands and batch files, check out information
about the search path for commands. Knowledge out this kind
always comes in handy for both users and programmers.

 

[Jeff Higgins]

I am trying to understand how to self-sign an applet.

<http://www.cert.org/blogs/certcc/2013/09/signed_java_applet_security_im.html>

 

[emf]

Into the text command prompt (sometimes called "shell") of
your operating system. Additional requirements might apply
such as having a command search path set up properly. This
is explained in the operating system literature, usually
separate from Java literature. A manual might already be
part of your operating system.


Search for tutorials or text books about your operating systems,
especially text commands and batch files, check out information
about the search path for commands. Knowledge out this kind
always comes in handy for both users and programmers.

Sorry, I did not make myself clear: I am looking for step by step
instructions. I have taken 2 classes on Java programming (and a long
time ago a class on DOS), and I do not intend in the near future to get
more classes. There should be some webpage out there that provides the
information I asked the way I asked.

emf

 

[emf]

<http://www.cert.org/blogs/certcc/2013/09/signed_java_applet_security_im.html>

Useless for what I asked and need. And, BTW, I had already come across
this webpage.

emf

 

[Jeff Higgins]

There should be some webpage out there that provides the
information I asked the way I asked.

There is. Keep looking.

 

[Jeff Higgins]

Useless for what I asked and need. And, BTW, I had already come across
this webpage.

That's one way to advertise your miserable web presence.

 

[Stefan Ram]

more classes. There should be some webpage out there that provides the
information I asked the way I asked.

To sign a jar file:

create a key pair in user.home/.keystore:

keytool -genkey

create a self-signed certificate:

keytool -selfcert

sign the file (use »mykey« literally, but change »example«):

jarsigner example.jar mykey

check the result:

jarsigner -verify -certs -verbose example.jar

 

[emf]

From
http://www-personal.umich.edu/~lsiden/tutorials/signed-applet/signed-applet.html


How To Create a Signed Applet

1. Package the applet into a JAR file. The applet must be in a JAR file
before a certificate can be attached to it. Use the jar JDK utility. If
the applet was previously referenced with the help of a codebase
attribute in <applet> tag, replace the codebase attribute with the
archive attribute. The value of the archive attribute is a URL of a JAR
file.

2. Create a public/private key pair. The command for this is

keytool -genkey

keytool is another SDK utility.

I opened the Command Prompt and navigated to the folder. OK so far.

It will prompt you for a password to

your keystore and for the remaining parameters, one of which is alias,
whose value is the name of the key. The keystore is a file that contains
your public/private key-pairs, and the public-keys of others with whom
you exchange information. See the documentation in the above link.

OK so far. I entered the password and the remaining parameters. Now,
where is the keystore? I do not see it in the bin folder. And I am not
sure which link it refers to.

...

Things are moving a little.

Thanks,

emf

 

[Hiram Hunt]

....

3) Create a UTF-8 text file (let's call it MyAppetManifest.txt)
with these three lines in it:

Permissions: all-permissions
Codebase: localhost 127.0.0.1
Application-Name: My Applet

Make sure each line ends with an NEWLINE (the Enter key).
A common error is to forget to hit Enter after that last line.
Currently (Java 7U45), the default is to run unsigned applets
in the sandbox, and signed applets with all permissions. So
the Permissions entry probably isn't needed. However, the default
has changed in the past and may change again, so including this
line seems a good idea to me. If your applet doesn't require
extra permissions, change "app-permissions" to "sandbox".
....

This seems relevant to the "may change again" part:

https://blogs.oracle.com/java-platform-group/entry/signing_applet_code_does_not

Sorry about the link getting split across lines. I am
having trouble finding an option to make my news reader
stop that.

-- Hiram Hunt ([email protected])

 

[Hiram Hunt]

....
Sorry about the link getting split across lines. I am
having trouble finding an option to make my news reader
stop that.

Sorry about the "sorry." The line split was just an
artifact on my end.

-- Hiram Hunt ([email protected])

 

[Joerg Meier]

Sorry about the "sorry." The line split was just an
artifact on my end.

If you surround a link with < >, usenet clients usually understand not to
split it, like so:

<http://www.verylonglink.com/sdjfhsd...hsdkjfhsdkfjsdhfkjsdhlfkjsdhfskdjfhsdjkfhkjsd>

Liebe Gruesse,
Joerg

 

[Arne Vajhøj]

Useless for what I asked and need.

Not what you asked for but still relevant.

And, BTW, I had already come across
this webpage.

Maybe Jeff's crystal ball that is supposed to tell him what pages
you have already found is not working properly.

Arne

 

[Arne Vajhøj]

Sorry, I did not make myself clear: I am looking for step by step
instructions.

You already got those. You posted link and quoted
part of it in your original post.

The reason why it is not clear to this is that you are not
familiar with the environment that you work in.

It makes sense to study how to work in that environment.

And anyway given that you did not tell what environment you are
working in, then it almost the only possible advice.

There should be some webpage out there that provides the
information I asked the way I asked.

Maybe.

But you are probably the only one that can recognize that
web page as being so.

Arne

 

[emf]

To sign a jar file:

Part I: Create an unsigned applet that just needs to be signed to work:

...

That was quite an interesting article. I have to read again more
carefully. The impression, however, that I have gotten so far is that
there have been serious security problems with Java applets, to have
them sign by an official authority is expensive, and that instead of
having the applet embedded in the webpage probably a better idea is to
have the visitor choose to download the jar file on his desktop, and
open the applet by clicking on it. Is my impression wrong?

emf

 

[Arne Vajhøj]

That was quite an interesting article. I have to read again more
carefully. The impression, however, that I have gotten so far is that
there have been serious security problems with Java applets,

Yes - there has been found a lot of those the last couple of years.

to have
them sign by an official authority is expensive,

Depends on the definition of expensive.

and that instead of
having the applet embedded in the webpage probably a better idea is to
have the visitor choose to download the jar file on his desktop, and
open the applet by clicking on it. Is my impression wrong?

It is a lot simpler.

But note that you are moving from a deployment model where
there may be holes int he sandbox security model to a model
with no sandbox at all, and from a web page model to a
desktop app model.

If you really need a signed applet in the first place, then
switching to a desktop app may not meet requirements.

Arne

 

[emf]

Yes - there has been found a lot of those the last couple of years.


Depends on the definition of expensive.




It is a lot simpler.

But note that you are moving from a deployment model where
there may be holes int he sandbox security model to a model
with no sandbox at all, and from a web page model to a
desktop app model.

If you really need a signed applet in the first place, then
switching to a desktop app may not meet requirements.

Arne

When I first tried to deploy the applet on a webpage, I was surprised
that there was a security risk, and so I had to use a different method
from the one in the textbook to read the data file to fill in the array.

However, there is a better solution: JavaScript. The reason I had chosen
Java for this program was because I wanted it to read a long text (csv)
file. But then I thought why not make the csv a js file, containing an
long array[54786][3]. I'll restrict the JavaScript program to the 2
significant planets, so the js file starts with

var ephem = [["19000101","27i43","10i08"], ["19000102",...

instead of

19000101,01i08,27i43,10i08,25c13,15c15
19990102,...

No security problem whatsoever. The 2 planets js file is smaller then
the 5 planets csv, but the jar file is even smaller, so I'll be looking
to see if it is already possible to use a zipped js file, otherwise the
js will have to do as is. And I will have a link to the jar file with
the 5 planets transits for those who are interested and trust me.

They have been extending JavaScript a lot. If Oracle is phasing out
applets as I've heard, JavaScript will be even more important for the
web that it is right now.

emf

 

[Arne Vajhøj]

Yes - there has been found a lot of those the last couple of years.


Depends on the definition of expensive.




It is a lot simpler.

But note that you are moving from a deployment model where
there may be holes int he sandbox security model to a model
with no sandbox at all, and from a web page model to a
desktop app model.

If you really need a signed applet in the first place, then
switching to a desktop app may not meet requirements.

When I first tried to deploy the applet on a webpage, I was surprised
that there was a security risk, and so I had to use a different method
from the one in the textbook to read the data file to fill in the array.

However, there is a better solution: JavaScript. The reason I had chosen
Java for this program was because I wanted it to read a long text (csv)
file. But then I thought why not make the csv a js file, containing an
long array[54786][3]. I'll restrict the JavaScript program to the 2
significant planets, so the js file starts with

var ephem = [["19000101","27i43","10i08"], ["19000102",...

instead of

19000101,01i08,27i43,10i08,25c13,15c15
19990102,...

No security problem whatsoever. The 2 planets js file is smaller then
the 5 planets csv, but the jar file is even smaller, so I'll be looking
to see if it is already possible to use a zipped js file, otherwise the
js will have to do as is. And I will have a link to the jar file with
the 5 planets transits for those who are interested and trust me.

As long as the CSV files are served from the same server as the JS, then
the JS should be able to retrieve and parse the CSV using
XmlHttpRequest.

They have been extending JavaScript a lot. If Oracle is phasing out
applets as I've heard, JavaScript will be even more important for the
web that it is right now.

I don't think Oracle is really changing anything regarding applets.
Applets has not been mainstream for more than a decade.

And JavaScript does not care. It is already 10000 more widely used
than Java applets.

Arne

 

[Richard Maher]

On 12/18/2013 7:08 AM, Arne Vajhøj wrote:
8<

I don't think Oracle is really changing anything regarding applets.

In order to cater for the inadequacies and introduced vulnerabilities of
WebStart and JNLP Oracle have knee-jerked their way into destroying the
sandboxed paradigm and made Applets almost impossible to activate
without reciting some incantation while waving a dead chicken over your
head :-(

For example: -
https://blogs.oracle.com/java-platform-group/entry/liveconnect_changes_in_7u45

Applets has not been mainstream for more than a decade.

Unless your eyes are open and can see websockets and worker-threads are
a joke and you have an appreciation of the power of Java on the client.

And JavaScript does not care. It is already 10000 more widely used
than Java applets.

Cheese definitely is used a lot more than chalk. Or "Why use a
screw-driver when you have a perfectly good hammer?"

Arne

Cheers Richard Maher.

BTW. I think the interesting one to watch will be Chrome's threatened
removal of the NPAPI in 2014.

http://blog.chromium.org/2013/09/saying-goodbye-to-our-old-friend-npapi.html

Google, Apple, and Microsoft know how powerful the Java plugin is. Just
a shame Oracle doesn't.

 

[emf]

On 12/18/2013 7:08 AM, Arne Vajhøj wrote:
8<


In order to cater for the inadequacies and introduced vulnerabilities of
WebStart and JNLP Oracle have knee-jerked their way into destroying the
sandboxed paradigm and made Applets almost impossible to activate
without reciting some incantation while waving a dead chicken over your
head :-(

For example: -
https://blogs.oracle.com/java-platform-group/entry/liveconnect_changes_in_7u45




Unless your eyes are open and can see websockets and worker-threads are
a joke and you have an appreciation of the power of Java on the client.


Cheese definitely is used a lot more than chalk. Or "Why use a
screw-driver when you have a perfectly good hammer?"


Cheers Richard Maher.

BTW. I think the interesting one to watch will be Chrome's threatened
removal of the NPAPI in 2014.

http://blog.chromium.org/2013/09/saying-goodbye-to-our-old-friend-npapi.html


Google, Apple, and Microsoft know how powerful the Java plugin is. Just
a shame Oracle doesn't.

I rewrote the program in JavaScript and now it runs perfectly without
any warnings. And it looks even better, since with Unicode I am able to
use symbols, while with Java that was problematic:

https://files.nyu.edu/emf202/public/nt/nataltransits.html

emf