harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Chris Gray <chris.g...@kiffer.be>
Subject Re: Probs with checking certificates from JarInputStream
Date Sat, 09 May 2009 06:33:12 GMT
On Friday 08 May 2009 17:33:45 Alexei Fedotov wrote:
> Hello Chris,
> It seems SignatureTest2.java keeps vanishing. Could it be that some
> paranoid anti-virus scanner removed the attachment?

Pooh, probably Scarlet's honky webmail. Blocking source files and letting 
through executable jars, that's what I call smart ... this time both attached 
and inline, using good ol' SMTP. Scroll down further and I will ramble on 
about a possible solution.

import java.io.BufferedInputStream;
import java.io.FileInputStream;
import java.util.Enumeration;
import java.util.jar.*;

class SignatureTest2 {
  static public void main(String[] args) {
    try {
      String filename = args.length == 0 ? "SignedTestBundle_1.0.0.jar" : 
      System.out.println("Opening file: " + filename);
      FileInputStream fis = new FileInputStream(filename);
      BufferedInputStream bis = new BufferedInputStream(fis, 8192);
      JarInputStream jis = new JarInputStream(bis);
      Manifest m = jis.getManifest();

      JarEntry je = jis.getNextJarEntry();
      while (je != null) {
        System.out.println("JarEntry: " + je);
        if (!je.isDirectory()) {
          String name = je.getName();
          if (!name.startsWith("META-INF/")) {
            java.security.cert.Certificate[] certs = je.getCertificates();
            if (certs == null) {
              System.out.println("No certificates");
            else {
              for (int i = 0; i < certs.length; ++i)
        je = jis.getNextJarEntry();
    catch (Throwable t) {

Note that this code doesn't even call closeEntry() on the meta-files it 
encounters, and yet it still works on RI 1.4/1.6. On harmony the *.DSA and 
*.SF files are simply skipped, without any entries being added to the 
metaEntries map. Adding an else clause in which meta-files are first 
exhaustively read([BII) and then closeEntry() is called seems to help a lot.

I think the answer is to treat all meta-files the way we now treat the 
manifest, i.e. provided they are presented in the "right" order we read them 
all in during the JarInputFile constructor and extract whatever data will 
later be needed by the JarVerifier. "Right" order means something like: meta-
files precede all non-meta files, manifest precedes all except possible the 
META-INF/ directory itself. This implies that we also suck in the META-
INF/INDEX.LST file and omy[deity] the META-INF/services directory if present, 
unless we can insist that these come after the signature data. Instead of 
mEntry we would have a whole queue of entries buffered and waiting for 
getNextEntry() to fish them out.

I'm not a fan of long-running constructors (imagine if the jar file were being 
read in from a slow server over a chunked HTTP stream - been there, done 
that), but in this case it's probably justified; arguably the JarInputStream 
object is not fully constructed until the signatures have been processed.

What a mess. What a format. What an API.



Chris Gray        /k/ Embedded Java Solutions      BE0809.435.306
Embedded & Mobile Java, OSGi    http://www.k-embedded-java.com/
chris.gray@kiffer.be                             +32 3 216 0369

View raw message