Details

    • Type: Improvement Improvement
    • Status: Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: None
    • Fix Version/s: None
    • Component/s: None
    • Labels:
      None
    • Environment:

      CLR 2.0; DOT.NET

      Description

      The FSDirectory.cs is the only place it have to be modified to apply FIPS compliance.

      I think, changing to use a FIPS compliant algorithm in general for the NET port of lucene to calc the lock
      file name is "safe" (mean: java-compat.) - the only case where I can see the
      may have to use the same algorithm is if a java-lucene impl. access the
      index with a writer at the same time as lucene.net - that would be rarely
      the case: writing to the same index is only allowed by one writer.

      First change required was to switch
      private static System.Security.Cryptography.MD5 DIGESTER; to
      private static readonly System.Security.Cryptography.HashAlgorithm DIGESTER;

      Last change is this:
      #if FIPS_COMLIANT
      // use a FIPS compliant algorithm (see also http://blog.aggregatedintelligence.com/2007/10/fips-validated-cryptographic-algorithms.html )
      DIGESTER = System.Security.Cryptography.SHA1.Create();
      #else
      // use the java compatible hash algorithm:
      DIGESTER = System.Security.Cryptography.MD5.Create();
      #endif

      I will attach the .patch to.

      1. FIPS_COMLIANCE.patch
        1.0 kB
        Torsten Rendelmann
      2. LUCENENET-175.rar
        0.9 kB
        Digy
      3. LUCENENET-175.rar
        1 kB
        Digy

        Issue Links

          Activity

          Hide
          Torsten Rendelmann added a comment -

          The patch for FSDirectory.cs (SVN 2.3.1)

          Show
          Torsten Rendelmann added a comment - The patch for FSDirectory.cs (SVN 2.3.1)
          Hide
          Digy added a comment -

          If there are no objections, I'll commit the patch

          DIGY

          Show
          Digy added a comment - If there are no objections, I'll commit the patch DIGY
          Hide
          Neal Granroth added a comment -

          The name of this patch and the proposed define is misspelled.
          It should read:
          #if FIPS_COMPLIANT
          not
          #if FIPS_COMLIANT

          Show
          Neal Granroth added a comment - The name of this patch and the proposed define is misspelled. It should read: #if FIPS_COMPLIANT not #if FIPS_COMLIANT
          Hide
          Torsten Rendelmann added a comment -

          Sure: "COMPLIANT" is the correct name.

          Another option would be to add a global (static?) configuration option to set FIPS compliance (default: false, JAVA compat.) by code. So no one have to recompile for the specific feature. But for that I did not know the code base enough to suggest how to proceed.

          Show
          Torsten Rendelmann added a comment - Sure: "COMPLIANT" is the correct name. Another option would be to add a global (static?) configuration option to set FIPS compliance (default: false, JAVA compat.) by code. So no one have to recompile for the specific feature. But for that I did not know the code base enough to suggest how to proceed.
          Hide
          Digy added a comment -

          I want to retard appling this patch to avoid a conflict with LUCENENET-164.

          DIGY

          Show
          Digy added a comment - I want to retard appling this patch to avoid a conflict with LUCENENET-164 . DIGY
          Hide
          George Aroush added a comment -

          A solution using an API, with the default being Java compliant is much better then conational compilation. The API must be in the SupportClass namespace (and in the file SupportClass.cs) to make it clear this is Lucene.Net specific support. The API must clearly document that setting it will break backward compatibility with Java Lucene index. This is currently missing (as a form of comment) from the patch.

          Also, I'm thinking we need a new README-Lucene.Net.txt file (or some other file name) in \trunk\C#\ to highlight Lucene.Net specific stuff like this one as well as #ziplib.

          – George

          Show
          George Aroush added a comment - A solution using an API, with the default being Java compliant is much better then conational compilation. The API must be in the SupportClass namespace (and in the file SupportClass.cs) to make it clear this is Lucene.Net specific support. The API must clearly document that setting it will break backward compatibility with Java Lucene index. This is currently missing (as a form of comment) from the patch. Also, I'm thinking we need a new README-Lucene.Net.txt file (or some other file name) in \trunk\C#\ to highlight Lucene.Net specific stuff like this one as well as #ziplib. – George
          Hide
          Digy added a comment -

          Hi George,

          http://mail-archives.apache.org/mod_mbox/lucene-java-dev/200903.mbox/%3C22008EEB-B5D6-4647-A519-4DA7415ECC92@mikemccandless.com%3E

          So, Java incompatibility is not the case.

          Applying that patch before 2.3.1 tag?

          DIGY

          Show
          Digy added a comment - Hi George, http://mail-archives.apache.org/mod_mbox/lucene-java-dev/200903.mbox/%3C22008EEB-B5D6-4647-A519-4DA7415ECC92@mikemccandless.com%3E So, Java incompatibility is not the case. Applying that patch before 2.3.1 tag? DIGY
          Hide
          George Aroush added a comment -

          Hi DIGY,

          I might be missing something obvious. If the algorithm is changed, will the lock file still be compatible with Java Lucene? That is, with this change, will I still be able to have a Java Lucene and a Lucene.Net application concurrently accessing (read and write) a Lucene index? If the answer is "yes", then this change is acceptable so apply the patch, otherwise we need to be extra careful, at least use conditional compilation or use my ealier suggestion.

          Regards,

          – George

          Show
          George Aroush added a comment - Hi DIGY, I might be missing something obvious. If the algorithm is changed, will the lock file still be compatible with Java Lucene? That is, with this change, will I still be able to have a Java Lucene and a Lucene.Net application concurrently accessing (read and write) a Lucene index? If the answer is "yes", then this change is acceptable so apply the patch, otherwise we need to be extra careful, at least use conditional compilation or use my ealier suggestion. Regards, – George
          Hide
          Digy added a comment -

          Hi George
          Please read the answer of Michael McCandless.
          http://mail-archives.apache.org/mod_mbox/lucene-java-dev/200903.mbox/%3C22008EEB-B5D6-4647-A519-4DA7415ECC92@mikemccandless.com%3E

          And since the patch uses conditional compilation (default: MD5) there will be no problem.

          DIGY.

          Show
          Digy added a comment - Hi George Please read the answer of Michael McCandless. http://mail-archives.apache.org/mod_mbox/lucene-java-dev/200903.mbox/%3C22008EEB-B5D6-4647-A519-4DA7415ECC92@mikemccandless.com%3E And since the patch uses conditional compilation (default: MD5) there will be no problem. DIGY.
          Hide
          Digy added a comment -

          A variant of previous patch.

          DIGY

          Show
          Digy added a comment - A variant of previous patch. DIGY
          Hide
          George Aroush added a comment -

          I like the API approach. However, this patch, as is, a Lucene.Net user has no way to pick between MD5 or SHA1 without a code change and compilation to pass in 'true' vs. 'false'.

          How about this. In the SupportClass, rather then passing 'false' in the call: GetHashAlgorithm(false), why not pass true / false base on an attribute in AssemblyInfo.cs? If the attribute is missing, or its value isn't valid, then default to MD5.

          If you agree, I suggest:

          1) [assembly: AssemblyUseSHA1("false")]
          2) If 'AssemblyUseSHA1' is missing or its value isn't 'true' (match case), then default to MD5.

          Show
          George Aroush added a comment - I like the API approach. However, this patch, as is, a Lucene.Net user has no way to pick between MD5 or SHA1 without a code change and compilation to pass in 'true' vs. 'false'. How about this. In the SupportClass, rather then passing 'false' in the call: GetHashAlgorithm(false), why not pass true / false base on an attribute in AssemblyInfo.cs? If the attribute is missing, or its value isn't valid, then default to MD5. If you agree, I suggest: 1) [assembly: AssemblyUseSHA1("false")] 2) If 'AssemblyUseSHA1' is missing or its value isn't 'true' (match case), then default to MD5.
          Hide
          Digy added a comment -

          Hi George,
          Your solution also needs recompilation of the code.
          What about a public, static field in SupportClass such as "FIPSCompliant"?

          DIGY

          Show
          Digy added a comment - Hi George, Your solution also needs recompilation of the code. What about a public, static field in SupportClass such as "FIPSCompliant"? DIGY
          Hide
          Digy added a comment -

          New Patch + deprecated LOCK_DIR (which is not used in Lucene anymore) removed.

          Show
          Digy added a comment - New Patch + deprecated LOCK_DIR (which is not used in Lucene anymore) removed.
          Hide
          Digy added a comment -

          Last patch applied.

          DIGY

          Show
          Digy added a comment - Last patch applied. DIGY
          Hide
          Drew Mace added a comment -

          Digy,
          We currently have an app using v2.9.4.1 and have run into the FIPSCompliant issue as described above. I got the latest stable source (2.9.4.4) and saw the Cryptography class in the SupportClass.cs file. Just to be sure, to run a FIPSCompliant version of Lucene.Net, we will have to recompile the source, changing the FIPSCompliant variable in the class to default to true? Is there an API alternative that is being considered to tackle this?

          Thanks in advance for you input.

          Drew

          Show
          Drew Mace added a comment - Digy, We currently have an app using v2.9.4.1 and have run into the FIPSCompliant issue as described above. I got the latest stable source (2.9.4.4) and saw the Cryptography class in the SupportClass.cs file. Just to be sure, to run a FIPSCompliant version of Lucene.Net, we will have to recompile the source, changing the FIPSCompliant variable in the class to default to true? Is there an API alternative that is being considered to tackle this? Thanks in advance for you input. Drew

            People

            • Assignee:
              Unassigned
              Reporter:
              Torsten Rendelmann
            • Votes:
              0 Vote for this issue
              Watchers:
              1 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Time Tracking

                Estimated:
                Original Estimate - 0.25h
                0.25h
                Remaining:
                Remaining Estimate - 0.25h
                0.25h
                Logged:
                Time Spent - Not Specified
                Not Specified

                  Development