Bug 794503 - Ensure all JON jar files are *NOT* signed and that there are no unintended consequences of that
Ensure all JON jar files are *NOT* signed and that there are no unintended co...
Product: RHQ Project
Classification: Other
Component: CLI (Show other bugs)
Unspecified Unspecified
high Severity medium (vote)
: ---
: JON 3.1.0
Assigned To: John Mazzitelli
Mike Foley
Depends On:
Blocks: jon310-sprint11/rhq44-sprint11 816253
  Show dependency treegraph
Reported: 2012-02-16 18:35 EST by Charles Crouch
Modified: 2015-02-01 18:27 EST (History)
4 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
: 816253 (view as bug list)
Last Closed: 2013-09-03 11:04:07 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Charles Crouch 2012-02-16 18:35:46 EST
In jon3.0.0 and 3.0.1 we had to not sign a jar (rhq-script-bindings-*.jar e.g. rhq-script-bindings-4.2.0.JON.3.0.1.GA.jar) due to the problems it was causing in the CLI. These problems are described in BZ-759173

This BZ is for the task of getting to the bottom of the actual cause of 759173, fixing it and re-enabling signing on the rhq-script-bindings-*.jar.
Comment 1 John Mazzitelli 2012-03-23 12:03:00 EDT
note to charles - if you prefix a bz number with "bug #" - bugzilla will display that as a link from right here in the comments view :)

see bug #759173
Comment 2 Charles Crouch 2012-03-29 15:59:50 EDT
I wonder if bug #759615 could also be related to this
Comment 3 John Mazzitelli 2012-03-29 16:10:51 EDT
(In reply to comment #2)
> I wonder if bug #759615 could also be related to this

I would bet it is. I actually forgot about that utility I wrote. I'll rescan the libs. I was just working on this today and can confirm if we sign all the jars in the CLI lib/ the error still happens.
Comment 4 John Mazzitelli 2012-03-29 16:20:31 EDT
to replicate the problem:

1. Start the CLI and connect to RHQ server (rhq-cli.sh -u rhqadmin -p rhqadmin)
2. Locate an web-app for a Tomcat Server (in this example 10218)
2. Run the following commands:
 a. webapp = ProxyFactory.getResource(10218)
 b. webapp.retrieveBackingContent("/foo/bar.war")

It doesn't matter what path you put in for b. - if you see something to the effect of:

TypeError: Cannot find function retrieveBackingContent

the problem exists.

To test, you need to sign the jars (note, step 3 just confirms the keystore is OK):

1. keytool -genkey -keystore /tmp/myKeystore -alias myself
2. keytool -selfcert -alias myself -keystore /tmp/myKeystore
3. keytool -list -keystore /tmp/myKeystore
4. jarsigner -keystore /tmp/myKeystore <a jar file in /lib> myself

Repeat step 4 for all the jars in the CLI lib/ and run the replication steps and the problem will happen.
Comment 5 John Mazzitelli 2012-03-29 17:40:52 EDT
I ended up refactoring the org.rhq.core.server package name to
org.rhq.core.domain.server thinking
https://bugzilla.redhat.com/show_bug.cgi?id=759615#c1 is the cause.

But the problem is still showing up. I thought this was the magic bullet, but I
guess not.
Comment 6 Charles Crouch 2012-03-29 18:49:38 EDT
(5:32:07 PM) ccrouch: mazz: so are you still seeing https://bugzilla.redhat.com/show_bug.cgi?id=759173#c9
(5:32:55 PM) ccrouch: that seems to describe the problem pretty succinctly
(5:32:59 PM) ccrouch: javassist.CannotCompileException: by java.lang.SecurityException: class "org.rhq.bindings.client.ResourceClientProxy5bc8d4d1a9859af5aab6a918a6d1029f0a8754cc60136a74fe735ef34d2ff4f1"'s
(5:35:15 PM) ccrouch: somewhere in the CLI we're using javassist to create classes, presumably extending ResourceClientProxy?, and the classes are being put in the wrong package
(5:36:16 PM) ccrouch: i.e. an existing package which has got signed stuff in it already
(5:36:16 PM) ccrouch: the classes just need to go into a different package
(5:44:51 PM) ccrouch: http://git.fedorahosted.org/git?p=rhq/rhq.git;a=blob;f=modules/enterprise/binding/src/main/java/org/rhq/bindings/client/ResourceClientFactory.java#l149
(5:46:39 PM) ccrouch: we shouldn't be using class.getName(), rather "org.rhq.our.new.random.package" + class.getSimpleName()
Comment 7 John Mazzitelli 2012-03-30 09:50:24 EDT
OK, yes, this CLI log clearly states the issue:

2012-03-30 09:45:03,610 ERROR [RHQ Client Prompt Input Thread] (org.rhq.bindings.client.ResourceClientFactory)- Could not create custom interface for resource with id 10218
javassist.CannotCompileException: by java.lang.SecurityException: class "org.rhq.bindings.client.ResourceClientProxye56bc7edadf38ce9e6deadd7f7b3e77a98baef002ed39ce37a04eb3b457d4c28"'s signer information does not match signer information of other classes in the same package
	at javassist.ClassPool.toClass(ClassPool.java:1035)
	at org.rhq.bindings.client.ResourceClientFactory.defineCustomInterface(ResourceClientFactory.java:205)
	at org.rhq.bindings.client.ResourceClientFactory.getResource(ResourceClientFactory.java:79)
	at java.lang.reflect.Method.invoke(Method.java:597)
	at com.sun.script.javascript.RhinoScriptEngine.eval(RhinoScriptEngine.java:167)
	at javax.script.AbstractScriptEngine.eval(AbstractScriptEngine.java:247)
	at org.rhq.enterprise.client.commands.ScriptCommand.execute(ScriptCommand.java:156)
	at org.rhq.enterprise.client.ClientMain.executePromptCommand(ClientMain.java:364)
	at org.rhq.enterprise.client.ClientMain$1.run(ClientMain.java:311)
	at java.lang.Thread.run(Thread.java:662)
Caused by: java.lang.SecurityException: class "org.rhq.bindings.client.ResourceClientProxye56bc7edadf38ce9e6deadd7f7b3e77a98baef002ed39ce37a04eb3b457d4c28"'s signer information does not match signer information of other classes in the same package
	at java.lang.ClassLoader.checkCerts(ClassLoader.java:806)
Comment 8 John Mazzitelli 2012-03-30 15:05:31 EDT
master commit: 3266294b4768113f529df1d77b03e056579389e5

see comment #4 for replication procedures.
Comment 10 Charles Crouch 2012-05-14 17:14:22 EDT
Pushing this to ONQA, any recent JON ER build should not be signed and would be 
suitable for testing this
Comment 11 Filip Brychta 2012-06-11 10:17:12 EDT
Verified on 3.1.0.GA for eap5 and eap6. It was working for both signed and unsigned jars. Found bug #830841 during verification.
Comment 12 Heiko W. Rupp 2013-09-03 11:04:07 EDT
Bulk closing of old issues in VERIFIED state.

Note You need to log in before you can comment on or make changes to this bug.