-
Notifications
You must be signed in to change notification settings - Fork 394
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
CVE-2015-1832 #974
Comments
Derby 10.11.1.1 is included in the target file and additionally derby.jar is included in the common/org.apache.derby.core plugin. |
Steve, whenever possible, artifacts should be consumed from the upstream providers. In this case, we can hopefully pull derby from maven. Inclusion should be the very last resort. Tycho is able to consume bundles from maven, however, we need to make sure that they are OSGified (e.g. proper export package and bundle name) |
I will change common/org.apache.derby.core to use the latest derby from maven and then try to replace the version of derby referenced in the target file. I'm not exactly sure how to do that but there are examples to follow, e.g. org.apache.axis. Update: It appears there's a way to specify a maven source in the target file. I'll try that. |
When you consume a jar file with maven, the jar file goes into your .m2 directory. In the case of derby, there are ant scripts that copy its jar file. I need to figure out how to specify derby as a dependency in a pom file and then locate the jar file in an ant script. Or specify the maven artifact in the target file, then it goes somewhere. Perhaps ${eclipse-home}/plugins. |
Now it's clear how all the jar files get into the birt runtime during the build. In birt-runtime-osgi, the tycho-p2-director-plugin puts them in a product folder and then the ant script copies them from there. However the WebViewerPackager.xml ant script is still copying the jar file from the old plugin project for derby. I'm trying to figure out if WebViewerPackager is even used any more. Update: Looks like WebViewerPackager is called from org.eclipse.birt.releng.birtbuilder/buildAll.xml and buildAll-package.xml, but it doesn't seem like they are called anywhere. I'll ask in discussion what releng is so I can understand it better. |
Do you mean the term "releng"? If so, it is short for release engineering. Anything that has to do with build/package/deploy/install/etc.. |
I would assume that the packagers create the standalone runtimes. Maybe a lot of that code got replaced by maven tycho. You could try to delete the build.xml and buildall.xml and run the build to see where it fails. |
The maven tycho builds create everything as far as I know, so I was wondering if the releng packages did anything useful. The readme files are very old -- 2007, for BIRT 2.2. I'll try your suggestion. Maybe we can get rid of them altogether. |
My local build succeeds after I delete all *.xml and *.sh files from releng.birtbuilder. There is no pom.xml in build/org.eclipse.birt.releng, build/org.eclipse.birt.releng.birtbuilder, or build/org.eclipse.birt.releng.util. There is a pom.xml in build/org.eclipse.birt.releng.birtbuilder/extras but it's not in any modules so it may not be invoked. Maybe I should create a separate issue for getting rid of the releng build folders. |
+1 |
In attempting to use the latest version of derby, I made I change that I though would work but it doesn't. In org.eclipse.birt.target.target, I removed the reference to the instance of derby in orbit and added a reference to derby in maven, like this:
The build fails with this:
The MANIFEST.MF file is:
This manifest is considerably different from the one in the orbit project in that it has far fewer packages exported and has a classpath where the orbit one doesn't. Just to be sure I also compared orbit 10.11 in maven to the orbit artifact and saw the same differences. Apparently orbit is applying a special manifest. I'm going to have to try to replicate that in a project within birt. |
My five-cent, I have not tested this. |
@claesrosell I think the expression from my father's time was "My 2 cents", but there's been inflation since then. Before I saw your comment I had already created a plugin wrapper that references derby 10.15 via maven, and to my surprise, it actually builds successfully. But my build doesn't do any tests so I'm going to create a PR and see if it can survive the CI build. |
Replace common/org.apache.derby.core with common/org.apache.derby using the latest derby in maven Signed-off-by: Steve Schafer <[email protected]>
Steve any progress on this? |
The org.apache.derby library is used elsewhere already and there are newer versions available that we can start to use too. eclipse-birt#974 eclipse-birt#1286
I got rid of the derby.core thing because other parts were already using org.apache.derby. I thought great, derby comes with OSGi metadata but it's very poor: I.e., the version is questionable and the symbolic name is unqualified. I'm meeting with Jonah next week to discuss how best to manage Orbit bundles going forward, so I don't think we can fix further this immediately. |
I see 4.14 is using derby 10.15.2. I ran a test report with the sampledb and it worked fine, so I don't think this vulnerability is any longer an issue. If the derby OSGI metadata is still a problem, it could be new issue. |
Hi @SteveSchafer-Innovent,
Am I missing something? |
Vulnerability in Apache Derby prior to 10.12.1.1.
https://nvd.nist.gov/vuln/detail/CVE-2015-1832#match-6066870
https://issues.apache.org/jira/browse/DERBY-6807
it is fixed in 10.12.1.1
The text was updated successfully, but these errors were encountered: