<html>
  <head>
    <meta content="text/html; charset=utf-8" http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    <p><br>
    </p>
    <br>
    <div class="moz-cite-prefix">On 1/23/17 3:17 PM, Tom Zeller wrote:<br>
    </div>
    <blockquote
      cite="mid:6F6E0156-86E4-4437-B032-9B46D961AE60@dragonacea.biz"
      type="cite">
      <pre wrap="">TL;DR We (meaning Brent) should just fix the test certs.</pre>
    </blockquote>
    <br>
    Yes.  I already opened a ticket about it last Wed so I wouldn't
    forget:  <a class="moz-txt-link-freetext" href="https://issues.shibboleth.net/jira/browse/OSJ-192">https://issues.shibboleth.net/jira/browse/OSJ-192</a><br>
    <br>
    <br>
    <blockquote
      cite="mid:6F6E0156-86E4-4437-B032-9B46D961AE60@dragonacea.biz"
      type="cite">
      <pre wrap="">

On last Friday’s dev call, we talked about the couple of OpenSAML tests[1] that are failing after the OpenJDK update which included MD5 in jdk.certpath.disabledAlgorithms. The real fix is, as Brent said, to remove/replace the test certs with MD5 signatures. However, as a temporary solution, I looked at enabling MD5 just for the failing tests. The only way I see to enable MD5 for the tests is via the <argLine/> configuration of the maven-surefire-plugin (which is what runs the tests), specifically :


        <argLine>-Djava.security.properties=${project.basedir}/java.security-overrides</argLine> 
</pre>
    </blockquote>
    <br>
    That works, but as I mentioned somewhere else (where?), that's
    probably sub-optimal b/c we then have to keep that file updated with
    any new/changed stuff going forward, and/or the tests would no
    longer function as a canary to whatever stuff they change wrt the
    JRE defaults in the future..<br>
    <br>
    <br>
    <blockquote
      cite="mid:6F6E0156-86E4-4437-B032-9B46D961AE60@dragonacea.biz"
      type="cite">
      <pre wrap="">

I was not able to set jdk.certpath.disabledAlgorithms as a system property (i.e. -D), I don’t see any doc that that should work.</pre>
    </blockquote>
    <br>
    That was my recollection also.  I'll address Scott's comment in the
    other msg in this thread.<br>
    <br>
    <br>
    <blockquote
      cite="mid:6F6E0156-86E4-4437-B032-9B46D961AE60@dragonacea.biz"
      type="cite">
      <pre wrap="">

Also, calling Security.setProperty() in the test itself via @BeforeClass didn’t work either, I guess because those security properties were instantiated already, I don’t know.</pre>
    </blockquote>
    <br>
    Hmm, it may only read them once, or something.  Might have better
    luck with @BeforeSuite, but probably isn't worth messing with. 
    Hopefully I can just fix the tests soon. I'll try this week, if I
    can hunt down my cmd line openssl CA scripts.<br>
    <br>
    <br>
    <blockquote
      cite="mid:6F6E0156-86E4-4437-B032-9B46D961AE60@dragonacea.biz"
      type="cite">
      <pre wrap="">

Thing is, we already override the maven-surefire-plugin <argLine/> in the parent-v3 POM for Cobertura, and the <argLine/>s are not additive, so the Maven configuration will get messier for Java 7. Not a huge deal, but I'd rather start building with Java 8 (keeping -source and -target at 1.7 and adding -Xbootclaspath, would take a little work to make sure we get it right).</pre>
    </blockquote>
    <br>
    That all does sound particularly nasty.<br>
    <br>
  </body>
</html>