[13] Re: RFR 8217375: jarsigner breaks old signature with long lines in manifest

Philipp Kunz philipp.kunz at paratix.ch
Mon Jul 29 06:54:48 UTC 2019


Hi Max,

Yes, you are right. I confused it with an invocation of Compatibility
test I imagine should be done (maybe already is) like the previously
existing one for TSA compatibility. See some related mails below.
Invoking SignTwice with only the current jdk does not actually verify
any kind of compatibility in between different JDK versions and might
possibly even be skipped altogether. I thought of it as a template for
how to call it with several JDKs.

Regards,
Philipp




Date: Sun, 09 Jun 2019 12:05:47 +0200Subject: Re: Jarsigner
compatibility issue invalidating existing signaturesTo: Weijun Wang <we
ijun.wang at oracle.com>From: Philipp Kunz <philipp.kunz at paratix.ch>
> Hi Max,
> 
> Bug 8217375 is about compatibility between different jdk versions and
> cannot easily be tested inside just one jdk version like most other
> bugs. To get a really meaningful test I figure either lots of signed
> jar files have to be checked in, or the code that is changed and was
> used to sign jars has to be moved into the tests, or the current test
> uses previous jdk versions to produce and verify signed jars. The
> last option is the one I chose to prefer and I found that
> Compatibility test is a very close match I considered a pretty good
> fit.
> 
> Rather than extending Compatibility test, we could as well create
> some similar new test, but in my opinion it would duplicate too much.
> Compatibility test already comes with a list of previous jdks which
> can be re-used to verify inter-jdk-version signature compatibility. I
> would not opt to build up another such a configuration prerequisite
> and would rather re-use that existing infrastructure.
> 
> I already got quite an impression of the time it takes even with a
> small number of jdks. This is why I added new parameters to run the
> test with, all of which with the idea to default to values resulting
> in the previous behavior. If I did everything right, no-one would or
> should even notice the difference when running Compatibility with the
> same parameters as before.
> 
> Eventually I suggest that more tests are run which involve
> combinations of different jdk versions and that will sure add some
> time to process. Not all possible combinations of different
> parameters will have to be actually tested. For example I don't see
> necessity to try all possible combinations of TSA digests and
> signature algorithms because I consider them independent. What
> exactly should be tested is probably worth to discuss in more detail.
> 
> I don't currently have an updated version of the fix but I'll be glad
> to provide one with the first consent how to update it.
> BTW, did you not post your message to the mailing list intentionally?
> 
> Regards,
> Philipp


Date: Tue, 11 Jun 2019 08:41:52 +0200Subject: Re: Jarsigner
compatibility issue invalidating existing signaturesTo: Weijun Wang <we
ijun.wang at oracle.com>From: Philipp Kunz <philipp.kunz at paratix.ch>
> Hi Max,
> 
> In any case I prefer to include the change to Compatibility. I don't
> know if my role as a contributor would entitle me to insist but I
> certainly welcome if you could ask Compatibility's reviewer and
> maintainer. The P3 priority it got might help.
> 
> On the other hand, it might be feasible to cover those cases with
> some binary jars checked into the tests. I see it as a lesser
> desirable alternative but it might work. I'm still thinking about how
> these tests should look like in detail.
> 
> Regards,
> Philipp



Date: Thu, 23 May 2019 09:49:02 +0800Subject: Re: Jarsigner
compatibility issue invalidating existing signaturesTo: Philipp Kunz <p
hilipp.kunz at paratix.ch>From: Weijun Wang <weijun.wang at oracle.com>
> Hi Philipp,
> 
> ...
> 
> Is it necessary to update Compatibility.java? This test is maintained
> by SQE and they run it with a script internally. The test is already
> spending a lot of time and I do not want to add more.
> 
> ...
> 
> Thanks,
> Max



On Mon, 2019-07-29 at 09:43 +0800, Weijun Wang wrote:
> > On Jul 28, 2019, at 10:23 PM, Philipp Kunz <philipp.kunz at paratix.ch
> > > wrote:
> > 
> > Hi Max,
> > 
> > Glad to see SignTwice being taken from ProblemList. Is it working
> > now with the timeout added or does it still fail on windows?
> 
> It hasn't failed in the last few days.
> 
> > > I just ran a test job: SignTwice.java failed on Windows with
> > > `failed to clean up files after test`. Most likely a file is not
> > > closed.
> > 
> > For the key algs, "-DkeyAlgs=EC;" or "-DkeyAlgs=EC" might be
> > shorter for the same effect, but "-DkeyAlgs=EC;0" is all right as
> > well.
> > 
> > However, "-DdigestAlgs=SHA-256" will (far as I remember) not result
> > in a digest that exceeds the maximum manifest line width in its
> > encoded form as a base64 string and makes a difference. I strongly
> > suggest to keep "-DdigestAlgs=SHA-512" or any other digest
> > algorithm that tests line breaking of digests in signed jar file
> > manifests.
> 
> OK, I'll revert it some day, maybe as a part of JDK-8228456.
> 
> However, I believe that since SignTwice always uses the same JDK to
> sign and verify, the line width issue will not be a problem itself,
> right?
> 
> Thanks,
> Max
> 
> > Regards,
> > Philipp
> > 
> > 
> > 
> > 
> > 
> > 
> > On Tue, 2019-07-23 at 14:28 +0800, Weijun Wang wrote:
> > > Please review the patch below. This test signs the same jar
> > > multiple times. It's mainly about making sure the manifest and
> > > signature file can be updated correctly. There is no need to try
> > > different key algorithms. We can also use a faster digest
> > > algorithm.
> > > 
> > > Thanks,
> > > Max
> > > 
> > > diff --git a/test/jdk/ProblemList.txt b/test/jdk/ProblemList.txt
> > > --- a/test/jdk/ProblemList.txt
> > > +++ b/test/jdk/ProblemList.txt
> > > @@ -661,7 +661,6 @@
> > >  sun/security/tools/keytool/KeyToolTest.java                     
> > > 8224644 solaris-all
> > >  sun/security/tools/keytool/WeakAlg.java                         
> > > 8224644 solaris-all
> > >  
> > > -sun/security/tools/jarsigner/compatibility/SignTwice.java       
> > > 8228341 windows-all
> > >  sun/security/tools/jarsigner/warnings/BadKeyUsageTest.java      
> > > 8026393 generic-all
> > >  
> > >  javax/net/ssl/ServerName/SSLEngineExplorerMatchedSNI.java       
> > > 8212096 generic-all
> > > diff --git
> > > a/test/jdk/sun/security/tools/jarsigner/compatibility/SignTwice.j
> > > ava
> > > b/test/jdk/sun/security/tools/jarsigner/compatibility/SignTwice.j
> > > ava
> > > ---
> > > a/test/jdk/sun/security/tools/jarsigner/compatibility/SignTwice.j
> > > ava
> > > +++
> > > b/test/jdk/sun/security/tools/jarsigner/compatibility/SignTwice.j
> > > ava
> > > @@ -36,7 +36,7 @@
> > >   * @test
> > >   * @library /test/lib ../warnings
> > >   * @compile Compatibility.java
> > > - * @run main/othervm
> > > + * @run main/othervm/timeout=600
> > >   *  -Djava.security.properties=./java.security
> > >   *  -Duser.language=en
> > >   *  -Duser.country=US
> > > @@ -46,8 +46,8 @@
> > >   *  -DtestComprehensiveJarContents=true
> > >   *  -DtestJarUpdate=true
> > >   *  -Dstrict=true
> > > - *  -DkeyAlgs=EC;#RSA;#DSA;
> > > - *  -DdigestAlgs=SHA-512
> > > + *  -DkeyAlgs=EC;0
> > > + *  -DdigestAlgs=SHA-256
> > >   *  SignTwice
> > >   */
> > >  public class SignTwice {
> > > 




-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/security-dev/attachments/20190729/0718af75/attachment-0001.html>


More information about the security-dev mailing list