birt
birt copied to clipboard
CVE-2015-1832
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
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. All the persisted orbit repositories have derby 10.11 and the milestone builds don't have derby at all. I don't know how to get derby re-included in orbit. It would probably be easiest to include it as our own plugin, which would replace the existing org.apache.derby.core plugin, but I need to find out why it was done that way.
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:
<location includeDependencyScope="compile" includeSource="true" missingManifest="generate" type="Maven">
<dependencies>
<dependency>
<groupId>org.apache.derby</groupId>
<artifactId>derby</artifactId>
<version>10.15.2.0</version>
<type>jar</type>
</dependency>
</dependencies>
</location>
The build fails with this:
[ERROR] Cannot resolve project dependencies:
[ERROR] Software being installed: org.eclipse.birt.designer 4.10.0.qualifier
[ERROR] Missing requirement: org.eclipse.birt.feature.group 4.10.0.qualifier requires 'org.eclipse.equinox.p2.iu; org.apache.derby 0.0.0' but it could not be found
[ERROR] Cannot satisfy dependency: org.eclipse.birt.designer 4.10.0.qualifier depends on: org.eclipse.equinox.p2.iu; org.eclipse.birt.feature.group 0.0.0
[ERROR]
[ERROR] See https://wiki.eclipse.org/Tycho/Dependency_Resolution_Troubleshooting for help.
[ERROR] Cannot resolve dependencies of MavenProject: org.eclipse.birt:org.eclipse.birt.p2updatesite:4.10.0-SNAPSHOT @ /disk1/home/innovent/eclipse/birt-master/git/birt/build/org.eclipse.birt.p2updatesite/pom.xml: See log for details -> [Help 1]
The MANIFEST.MF file is:
Manifest-Version: 1.0
Ant-Version: Apache Ant 1.10.6
Created-By: 11+28 (Oracle Corporation)
Bundle-Vendor: Apache Software Foundation
Bundle-Name: Apache Derby 10.15
Bundle-Version: 10.15.2000000.1873585
Bundle-ManifestVersion: 2
Sealed: true
Bundle-Activator: org.apache.derby.osgi.EmbeddedActivator
Bundle-SymbolicName: derby
DynamicImport-Package: *
Export-Package: org.apache.derby.authentication,org.apache.derby.datab
ase,org.apache.derby.io,org.apache.derby.jdbc,org.apache.derby.vti
Class-Path: derbyshared.jar derbyLocale_cs.jar derbyLocale_de_DE.jar d
erbyLocale_es.jar derbyLocale_fr.jar derbyLocale_hu.jar derbyLocale_i
t.jar derbyLocale_ja_JP.jar derbyLocale_ko_KR.jar derbyLocale_pl.jar
derbyLocale_pt_BR.jar derbyLocale_ru.jar derbyLocale_zh_CN.jar derbyL
ocale_zh_TW.jar
Name: org/apache/derby/jdbc/
Sealed: false
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. The feature: "org.eclipse.birt.feature.group" has a reference to the bundle: "org.apache.derby", but the bundle from Maven seems to have the symbolic name: "derby". Try to change the features that reference "org.apache.derby" to only "derby".
@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.
Steve any progress on this?
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.
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, In eclipse birt-runtime-4.14 (both OSGI and non-OSGI versions), I can still see derby 10.11.1.1:
florin@debian:~/Downloads/birt$ unzip -t birt-runtime-4.14.0-202312020807.zip | grep derby_10.11
testing: ReportEngine/lib/org.apache.derby_10.11.1.1_v201605202053.jar OK
testing: WebViewerExample/WEB-INF/lib/org.apache.derby_10.11.1.1_v201605202053.jar OK
florin@debian:~/Downloads/birt$ unzip -t birt-runtime-osgi-4.14.0-202312020807.zip | grep derby_10.11
testing: ReportEngine/platform/plugins/org.apache.derby_10.11.1.1_v201605202053.jar OK
testing: WebViewerExample/WEB-INF/platform/plugins/org.apache.derby_10.11.1.1_v201605202053.jar OK
Am I missing something? Thank you