Platinum Edition Using HTML 4, XML, and Java 1.2
(Publisher: Macmillan Computer Publishing)
Author(s): Eric Ladd
ISBN: 078971759x
Publication Date: 11/01/98

The first file named in the filenames list is the name of the archive. The use of any remaining files named in this list is given in the options list:

•  c—Make a new archive.

•  m—Use an external manifest file, named as the second file in the filenames list.

•  M—Do not make a manifest file for this archive.

•  t—List the contents of this archive.

•  x—Extract the files named in the filenames list; if none, extract all the files in the archive.

•  f—Specifies that the archive is named as the first file in the filenames list.

•  v—Specifies that the utility should produce verbose information while it performs the actions described by the other options.

•  0—Stores files in the archive without using compression.

---

NOTE:  Unlike other utilities you may be familiar with, jar doesn’t require that you use / or - in front of the options.

---

In order to make our new archive, then, we write

jar cf MyApplet.jar *.class images/*.gif

If you had prepared a manifest file in the text file MyApplet.MF, you would write

jar cfm MyApplet.jar MyApplet.MF *.class images/*.gif

---

CAUTION:  

A package name such as com.mcp.que.platinumHTMLXMLJava.chapter41 means that the class file is located in the com/mcp/que/platinumHTMLXMLJava.chapter41 directory underneath one of the directories named in the CLASSPATH environment variable. Be sure to place these class files into the proper directory before installing them into the JAR, or the JVM won’t be able to find the class file.

---

You can examine a JAR file by using any PKZIP-compatible tool, including the jar utility itself. To get a listing of the files in MyApplet.jar, type

jar tf MyApplet.jar

Suppose you want to make a copy of a file that’s come to you in a JAR file. Use the x option. To read the manifest file out of MyApplet.jar, for example, type

jar xf MyApplet.jar MyApplet.MF

Signing Your JARs

Regardless of what your JAR file contains, there are times when you want to be able to prove to the person using it that you are, indeed, the originator, and that no one has tampered with the contents after you made the JAR. If your JAR contains an applet, this need is particularly critical because, without such proof, applets are left in an untrusted state and will have no access to the hard drive or operating system services on the machine to which they’re downloaded.

You can provide this guarantee by digitally signing your JAR. In order to understand how to set up a digital signature, you need to understand a little about cryptography.

Understanding Public Key Encryption

Many years ago encryption was the province of the military and the diplomats. You kept messages secret by combining the message with a secret piece of information called a key. The receiver needed a copy of the key. With the key and the proper equipment, anyone could decrypt a message. Figure 41.7 illustrates one of these old systems.

FIGURE 41.7  Old-style encryption systems were based on secret keys.

Introducing Public Key Technology In more recent days, cryptographers have invented public key encryption. A public key encryption system is based on two pieces of information, or keys. These keys come in pairs—they must be used together. One of these keys is secret and is kept under tight security by the owner. The other is public and may be distributed widely. Figure 41.8 illustrates how a public key encryption system works.

FIGURE 41.8  Public key encryption is based on the fact that no one can read a message that was signed with one key unless he or she has the other key.

Suppose you want to send a message (which could be a JAR file) and be able to assure the person receiving the message that the message is really from you and hasn’t been tampered with. You would start by encrypting the message with your private key. Because only you have your private key—you’re being very careful to keep it secret—only you could have produced this encrypted file. Your public key is well known—assume the recipient already has a copy. When the recipient receives your message, he or she attempts to decrypt the message by using your public key. Remember that these keys work together—only one key can successfully decode a message encrypted by your private key. If the recipient is able to decrypt the message with your public key, he or she can safely assume that it was signed by you.

---

CAUTION:  

You should never send your private key out over the Internet. Most of the time, it never even needs to leave your computer. When you generate it, choose a good long (multiword) passphrase no one else is likely to guess, but that you’re certain to remember.

---

Why Do You Need a Certificate? A flaw is present in this system—I claimed that your public key was well known and that the recipient already has a copy. That’s not true—the recipient doesn’t necessarily know you, and he or she probably doesn’t have a copy of your public key. You could send one by email, but then how could the recipient know that that message didn’t come from someone impersonating you?

The solution is to have your public key embedded in a message that is signed by someone whom both you and the recipient trust. Such a message is called a digital certificate. The current standard version is X.509 version 3, so these certificates are often called X.509v3 certificates. The “someone” whom both parties trust is called a Certification Authority, or CA. If both you and the recipient work for the same company, or if the recipient trusts my employer, you might present a certificate signed by my company CA. If the two parties have no other relationship, you might present a certificate signed by a public Certification Authority, such as Verisign (http://www.verisign.com/). If the recipient is the trusting sort, he or she might even accept a certificate you signed yourself—a self-certifying certificate.