Ivy
  1. Ivy
  2. IVY-1061

ChecksumHelper.check() fails on non-ASCII platforms

    Details

    • Type: Bug Bug
    • Status: Open
    • Priority: Major Major
    • Resolution: Unresolved
    • Affects Version/s: 2.0, 2.1.0, 2.3.0-RC1
    • Fix Version/s: None
    • Component/s: Core
    • Labels:
      None
    • Environment:

      z/OS 1.9

      java version "1.6.0"
      Java(TM) SE Runtime Environment (build pmz3160sr3-20081108_01(SR3))

      Description

      As part of the checksum verification algorithm, ChecksumHelper converts the checksum file to a String:

      public static void check(File dest, File checksumFile, String algorithm) throws IOException {
          String csFileContent = FileUtil.readEntirely(
              new BufferedReader(new FileReader(checksumFile))).trim().toLowerCase(Locale.US);
      //...
      

      FileReader reads the file as a sequence of bytes, which FileUtil.readEntirely() then converts to a String using the platform's default encoding, because no other encoding is explicitly specified.

      The checksum can be a local file or retrieved over the network. Currently, the encoding of the checksum file depends on the default encoding of the platform that generated it.

      On z/OS, the default encoding is EBCDIC (IBM-1047). Therefore, if the checksum file was created on an ASCII system, the checksum String ends up as garbage and the checksum comparison fails.

      In my environment, specifying ISO-8859-1 explicitly both when encoding and decoding the checksum String solves the problem:

      Index: src/java/org/apache/ivy/plugins/resolver/RepositoryResolver.java
      ===================================================================
      --- src/java/org/apache/ivy/plugins/resolver/RepositoryResolver.java	(revision 763312)
      +++ src/java/org/apache/ivy/plugins/resolver/RepositoryResolver.java	(working copy)
      @@ -234,7 +234,7 @@
               File csFile = File.createTempFile("ivytemp", algorithm);
               try {
                   FileUtil.copy(new ByteArrayInputStream(ChecksumHelper.computeAsString(src, algorithm)
      -                    .getBytes()), csFile, null);
      +                    .getBytes("ISO-8859-1")), csFile, null);
                   repository.put(DefaultArtifact.cloneWithAnotherTypeAndExt(artifact, algorithm,
                       artifact.getExt() + "." + algorithm), csFile, dest + "." + algorithm, overwrite);
               } finally {
      Index: src/java/org/apache/ivy/util/ChecksumHelper.java
      ===================================================================
      --- src/java/org/apache/ivy/util/ChecksumHelper.java	(revision 763312)
      +++ src/java/org/apache/ivy/util/ChecksumHelper.java	(working copy)
      @@ -23,6 +23,7 @@
       import java.io.FileReader;
       import java.io.IOException;
       import java.io.InputStream;
      +import java.io.InputStreamReader;
       import java.security.MessageDigest;
       import java.security.NoSuchAlgorithmException;
       import java.util.HashMap;
      @@ -53,7 +54,7 @@
            */
           public static void check(File dest, File checksumFile, String algorithm) throws IOException {
               String csFileContent = FileUtil.readEntirely(
      -            new BufferedReader(new FileReader(checksumFile))).trim().toLowerCase(Locale.US);
      +            new BufferedReader(new InputStreamReader(new FileInputStream(checksumFile), "ISO-8859-1"))).trim().toLowerCase(Locale.US);
               String expected;
               if (csFileContent.indexOf(' ') > -1
                       && (csFileContent.startsWith("md") || csFileContent.startsWith("sha"))) {
      

      I'm not sure whether this is a sufficiently generic solution - for example, it could cause backwards compatibility issues. An alternative might be to attempt to guess the encoding of the checksum file when it is read, based on the byte values.

      Another workaround could be to specify the system property -Dfile.encoding=ISO-8559-1 on the command line, but this is a bit of a big hammer. In particular, it is not suitable when Ivy is used within an application where we don't to assume all input is ISO-8559-1. This is related to issue IVY-1060.

        Activity

        There are no comments yet on this issue.

          People

          • Assignee:
            Unassigned
            Reporter:
            Robin Fernandes
          • Votes:
            2 Vote for this issue
            Watchers:
            1 Start watching this issue

            Dates

            • Created:
              Updated:

              Development