New TSA for SHA256

[Marc R. Hoffmann]

Hi Evgeny,

I received an email today from Thawte that Oracle will remove SHA1 support for their JDKs.

We're therefore required to use their new SHA256 TSA at

http://sha256timestamp.ws.symantec.com/sha256/timestamp

according to their documentation: https://search.thawte.com/support/ssl-digital-certificates/index?page=content&id=INFO1428

Can you please check whether our build works with this TSA?

Thx,
-marc

[Evgeny Mandrikov]

Hi Marc,

No pb - will do tomorrow.

--
You received this message because you are subscribed to the Google Groups "JaCoCo Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jacoco-dev+...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Evgeny Mandrikov]

Hi Marc,

This goes down to https://bugs.openjdk.java.net/browse/JDK-8156556 So I doubt that it will work as is, because we use JDK 5 tools during release and no changes has been backported to JDK 5 jarsigner - it uses hardcoded value of SHA1. I might check if we'll be able to use different JDKs for different tools. But this looks like an overkill. Much simpler would be to say that release can be done with newer JDK with compilation into JDK 5 bytecode. I believe that this is safe enough given all our safety-net. WDYT?

On Tue, Sep 20, 2016 at 10:21 PM Marc R. Hoffmann <hoff...@mountainminds.com> wrote:

--

[Marc R. Hoffmann]

Hi Evgeny,

as we have check builds on all supported JDKs we can verify the release branch before actually doing the release. We just have to make sure that the produced results do have the correct bytecode version.

But I wonder whether JRE 5 can verify JAR files using a different TSA hash than SHA1?

Maybe finally the time has come to drop Java 5 runtime support.

Cheers,
-marc

[Evgeny Mandrikov]

 

But I wonder whether JRE 5 can verify JAR files using a different TSA hash than SHA1? 

This is indeed interesting question, hadn't thought about this, will check. 

[Evgeny Mandrikov]

Hi Marc,

I did test and you're right as usual: jarsigner from JDK 5 can't verify JAR with SHA256-Digest.

Also did test of build of EclEmma with such JaCoCo snapshot:

Eclipse 3.8.2, 4.3.2, 4.4.2, 4.5.2, 4.6 - all fine,

however Eclipse 3.5, 3.6.2, 3.7.2  show following error, even if started with JDK 8 :

[Evgeny Mandrikov]

In fact as you can see on previous screenshot, artifacts signed by Eclipse already use SHA256-Digest (ASM from Orbit) and so not installable on Eclipse 3.5-3.7.2, the same applies on EclEmma signed by Eclipse:

[Marc R. Hoffmann]

Hi Evgeny,

thanks for testing this! Maybe we should simplify things a bit:

1) Signing

The primary use case for signing JaCoCo artifacts was the EclEmma plug-in. We will need to consume JaCoCo from Orbit now, where bundles get signed by eclipse.org anyways. Proposal: As soon as we're releasing EclEmma from Eclipse.org we stop signing JaCoCo artifacts.

2) Minimum supported JRE

Im the meantime we're testing against 5(!) JRE versions (not to mention the subtile differences between update versions). Java 5 had its EOF in 2009. Proposal: We drop support for Java 5 for JaCoCo as well as for EclEmma. Both will be shipped with Java 6 class file version.

What do you think?

Cheers,
-marc

--

You received this message because you are subscribed to the Google Groups "JaCoCo Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jacoco-dev+...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

-- 
Marc Hoffmann
hoff...@mountainminds.com
_______________________________________________
Mountainminds GmbH & Co. KG

Nussbaumstr. 4 * 80336 Muenchen * Germany 
Phone/Fax +49-700-68664637 * 0700-MTNMINDS

Registergericht Muenchen * HRA 80201
Mountainminds Verwaltungs GmbH
Registergericht Muenchen * HRB 143183
Geschaeftsfuehrer Marc Hoffmann

[Evgeny Mandrikov]

Current builds of EclEmma at Eclipse still consume JaCoCo from Maven Central repository, not from Orbit. Going thru Orbit is definitely an option for signing, even if imposes some additional steps, they supposed to be a bit simpler since now I have committer status.

While Eclipse 4.3 requires Java 6 and Eclipse 4.6 requires Java 8, this doesn't mean that development can't target Java 5. Also if we put aside signing question and size of test matrix, then I'm not sure that there are real benefits from Java 6 for JaCoCo. Having said this - I'm not against of raising requirement, just want to be sure that decision is weighted.

Regards,

Evgeny

[Evgeny Mandrikov]

FYI everything is prepared for inclusion of JaCoCo 0.7.7 into Eclipse Orbit, just waiting CQs approval - https://bugs.eclipse.org/bugs/show_bug.cgi?id=507110

[Evgeny Mandrikov]

FYI JaCoCo has been approved and added into Orbit, and already available in nightly builds.

From here I'm wondering if there are any reasons to maintain duplicate of OSGi metadata in JaCoCo ( see https://git.eclipse.org/c/orbit/orbit-recipes.git/tree/jacoco/org.jacoco.core_0.7.7/osgi.bnd ) ? To me seems that EclEmma is the only consumer of OSGi bundles. Also should be said that these metadata are not verified actually during JaCoCo builds and complicate procedure of release.

Note that bundle "org.jacoco.ant" wasn't added to Orbit, but again - I doubt that it is used by someone as OSGi bundle (even not by EclEmma), and in any case I assume that it won't be a problem to add it also.

Hence I propose to reduce maintenance efforts a bit by removal of this metadata.

WDYT? If there is no objections, then I can prepare changes, making this change part of change notes and announcement during next release.

[Marc Hoffmann]

Hi Evgeny,

as a OSGi fan and daily user (still) I would like to behave as a good
OSGi citizen and ship proper manifests in our atifacts. As we completely
changed to Maven (POM first) we definitely need to create them during
the build (and remove all MANIFEST.MF from source tree). We already
created a task for this:

https://github.com/jacoco/jacoco/issues/211

I wonder whether Orbit build allows to use original decaration intead of
re-declaring them.

Cheers,
-marc

[Evgeny Mandrikov]

Yup, I remember this task. autogeneration != verification , however indeed it will probably simplify release. My main argument was: I doubt that someone consumes our OSGi metadata especially from Maven Central repository and anyway artifacts with metadata will be available from Orbit instead of Maven Central.

Regarding re-use: As an example even if ASM provides OSGi metadata, Orbit bundle regenerates it. But maybe for the good - to fix mistakes of original. However even if JaCoCo metadata can be used as is, for the current version I didn't found a way to properly sign bundle without removal of original MANIFEST.MF - see http://git.eclipse.org/c/orbit/orbit-recipes.git/commit/?id=e255e5b4b487197a0df810f6746ebcefc8e50c25

All in all - if you are not convinced, then okay, let's keep it and resolve this ticket about auto-generation.

Regards,

Evgeny