Re: [cross-project-issues-dev] A funny thing happened on the way to Mars.2 -- in Orbit

2016-02-16 Thread Laurent Goubet 

Hi,

This seems strangely reminiscent of 
https://bugs.eclipse.org/bugs/show_bug.cgi?id=458925 . Though it was the 
reverse, the jar file was good but the pack200 was not.


That time was affecting orbit too. We might want to have a script 
running to check the signatures over there with each build?


Laurent Goubet
Obeo

On 16/02/2016 16:48, Andreas Sewe wrote:

Hi,

David M Williams wrote:

But since there is a "bad" one out there (in Orbit, at least) with the
same version, I was suggesting to verify if it was in your project
repositories to make sure you had the good one.

If it is the good one, you get "jar verified" as above.

If it is "the bad one" it will be pretty obvious:

$ jarsigner -verify
org.apache.httpcomponents.httpclient_4.3.6.v201411290715.jar
jarsigner: java.lang.SecurityException: SHA1 digest error for
org/apache/http/client/cache/HttpCacheEntry.class

FWIW, I just found out that only the plain JAR in Orbit is "bad"; the
JAR.pack.gz is not, i.e., it unpack200s to a JAR that verifies just fine
[1]. If your build prefers pack200ed JARs over plain JARs, you should
get a "good" JAR from Orbit, but of course it's better to double-check
what you are distributing exactly.

Best wishes,

Andreas

[1] 



--

*Laurent Goubet*
Consultant
+33 2 51 13 51 42



7 Boulevard Ampère - Carquefou - France
*obeo.fr*  | *twitter* 
 | *linkedin* 



<>___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
To change your delivery options, retrieve your password, or unsubscribe from 
this list, visit
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev

Re: [cross-project-issues-dev] A funny thing happened on the way to Mars.2 -- in Orbit

2016-02-16 Thread Andreas Sewe 
Hi,

David M Williams wrote:
> But since there is a "bad" one out there (in Orbit, at least) with the
> same version, I was suggesting to verify if it was in your project
> repositories to make sure you had the good one.
> 
> If it is the good one, you get "jar verified" as above.
> 
> If it is "the bad one" it will be pretty obvious:
> 
> $ jarsigner -verify
> org.apache.httpcomponents.httpclient_4.3.6.v201411290715.jar
> jarsigner: java.lang.SecurityException: SHA1 digest error for
> org/apache/http/client/cache/HttpCacheEntry.class

FWIW, I just found out that only the plain JAR in Orbit is "bad"; the
JAR.pack.gz is not, i.e., it unpack200s to a JAR that verifies just fine
[1]. If your build prefers pack200ed JARs over plain JARs, you should
get a "good" JAR from Orbit, but of course it's better to double-check
what you are distributing exactly.

Best wishes,

Andreas

[1] 

-- 
Codetrails GmbH
The knowledge transfer company

Robert-Bosch-Str. 7, 64293 Darmstadt
Phone: +49-6151-276-7092
Mobile: +49-170-811-3791
http://www.codetrails.com/

Managing Director: Dr. Marcel Bruch
Handelsregister: Darmstadt HRB 91940
___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
To change your delivery options, retrieve your password, or unsubscribe from 
this list, visit
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev

Re: [cross-project-issues-dev] A funny thing happened on the way to Mars.2 -- in Orbit

2016-02-16 Thread David M Williams 
> > This  will only be relevant to you if you use
> > org.apache.httpcomponents.httpclient
> > and exactly version
> > 4.3.6.v201411290715
> We seem to have it in our Oomph repos. I've checked this:
> 
>  estepper@build:~/oomph/drops/release/1.3.0/plugins> jarsigner -
> verify -certs 
> org.apache.httpcomponents.httpclient_4.3.6.v201411290715.jar
>  jar verified.
> 
> So, we're good, right?
> 

Yes, you're good. 

And, to clarify, that is the right version to have in your Mars.2 repos 
(if you use it at all). 

But since there is a "bad" one out there (in Orbit, at least) with the 
same version, I was suggesting to verify if it was in your project 
repositories to make sure you had the good one. 

If it is the good one, you get "jar verified" as above. 

If it is "the bad one" it will be pretty obvious: 

$ jarsigner -verify 
org.apache.httpcomponents.httpclient_4.3.6.v201411290715.jar 
jarsigner: java.lang.SecurityException: SHA1 digest error for 
org/apache/http/client/cache/HttpCacheEntry.class

And, FYI, the code has not been "tampered with" in any "bad" way. It is 
just that since it is not signed correctly so p2 and others will not 
install it. 

Thanks, 




___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
To change your delivery options, retrieve your password, or unsubscribe from 
this list, visit
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev

Re: [cross-project-issues-dev] A funny thing happened on the way to Mars.2 -- in Orbit

2016-02-15 Thread Eike Stepper 

Am 16.02.2016 um 04:12 schrieb David M Williams:
I just wanted to call everyone's attention to Orbit *_Bug 487833_* 
.


This  will only be relevant to you if you use
org.apache.httpcomponents.httpclient
and exactly version
4.3.6.v201411290715

We seem to have it in our Oomph repos. I've checked this:

estepper@build:~/oomph/drops/release/1.3.0/plugins> jarsigner -verify -certs 
org.apache.httpcomponents.httpclient_4.3.6.v201411290715.jar

jar verified.

So, we're good, right?

Cheers
/Eike


http://www.esc-net.de
http://thegordian.blogspot.com
http://twitter.com/eikestepper



___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
To change your delivery options, retrieve your password, or unsubscribe from 
this list, visit
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev

[cross-project-issues-dev] A funny thing happened on the way to Mars.2 -- in Orbit

2016-02-15 Thread David M Williams 
I just wanted to call everyone's attention to Orbit Bug 487833. 

This  will only be relevant to you if you use 
org.apache.httpcomponents.httpclient
and exactly version
4.3.6.v201411290715

It turns out there are two version of that bundle, with same version and 
qualifier. The only difference is that one is correctly signed, and the 
other is not correctly signed. 

One that is not correctly signed is in two Orbit R-repositories:

 R20151221205849  Mars.2
 R20151118145958  Mars.1 Patches 

By lucky coincidence, the one that is in the Sim. Release repos is the 
correctly signed one (including Mars.2 Sim. Release "maintenance" 
(staging) repository). 

Therefore I am NOT suggesting we "re-spin" Mars.2.  But, I am proposing 
that right after Mars.2, Orbit will declare another R-build that is 
exactly the same as the Mars.2 repo, but with that bundle correctly 
signed. It will have version 4.3.6.v201411290715B  (the 'B' making it 
"higher" than the sometimes-incorrectly-signed one). 

I thought I would mention this now for two reasons: 
A. If anyone has a concrete reason how this plan would cause problems, let 
us know by commenting in Bug 487833. And, 
B. If anyone has this bundle/version your own "project repositories" it 
would be a good time for you verify it is OK, and if not, to decide what 
to do. 
It is easy to check. From the plugins directory of your repository, run 
jarsigner -verify  org.apache.httpcomponents.httpclient_
4.3.6.v201411290715.jar

I am hoping no one else has the issue because for years  we in the Eclipse 
Platform get this bundle from ECF so it is pretty much "everywhere" 
already. 

The problem in Orbit was introduced some time towards the end of last 
year.  It was probably caused in part by some error I made when making an 
Orbit build change, or making that "Patch Build"? 

But another reason for the problem is that a infrastructure's signing 
service does not always work as expect. Sometimes "skipping" a jar that is 
already signed, but sometimes re-signing it again with Java 6.  The reason 
I am guessing that is due to Bug 487087, where ECF is having trouble 
getting that bundle "returned" from signing service correctly (that is, 
correctly untouched).  Any Buckminster Build experts reading this that 
know how to set an environment variable to force Java 8 to be used during 
signing could probably solve that bug for ECF. 

Thanks all, 




 



___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
To change your delivery options, retrieve your password, or unsubscribe from 
this list, visit
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev