Community
Participate
Working Groups
A number of open source libraries bundled with BIRT 4.3.1 OSGi runtime have security bulletins registered against them. axis javax.xml.rpc_1.1.0.v201209140446.jar (bundled jaxrpc.jar) javax.xml.soap_1.2.0.v201005080501.jar (bundled saaj.jar) derby org.apache.derby.core_10.5.1.1_v20120820.jar batik org.apache.batik.css_1.6.0.v201011041432.jar org.apache.batik.pdf_1.6.0.v201105071520.jar poi uk.co.spudsoft.birt.emitters.excel_4.3.1.v201308301349.jar (bundled poi-ooxml-3.9-20121203.jar) org.apache.poi_3.9.0.v201303080712.jar Most of these versions are still in the latest release. Issues identified using Dependency Check: https://www.owasp.org/index.php/OWASP_Dependency_Check
Hi Team, Thank you for your attention to this defect. May we know the specific milestone that will include the changes, so we may plan for validation testing? Thanks!
Can somebody from the project team or PMC please address this?
Hi, Can you provide an update to this defect? It is targeted for 4.8 but is still open. Also, do you have any information to share regarding whether we can disregard the vulnerabilities in these libraries due to the specific implementation? For example, the issues with POI seem to require a "specially crafted" file, for example: CVE-2017-5644 Apache POI in versions prior to release 3.15 allows remote attackers to cause a denial of service (CPU consumption) via a specially crafted OOXML file, aka an XML Entity Expansion (XEE) attack. If there is no way to exploit this - since the documents are generated by BIRT - then we would not require it to be updated. Thank you, Angela
Hi Angela, It looks like you are still using very old version: BIRT 4.3.1 while last release build is 4.8. It has been 5 release gap, so a lot of issues have been resolved. Here is updated result. axis javax.xml.rpc_1.1.0.v201209140446.jar (bundled jaxrpc.jar) ->This plugin is obsolete. javax.xml.soap_1.2.0.v201005080501.jar (bundled saaj.jar) -> Now 1.3.0 derby org.apache.derby.core_10.5.1.1_v20120820.jar->This plugin is obsolete. org.apache.derby.10.11.1.1 is used instead. batik org.apache.batik.css_1.6.0.v201011041432.jar->Now 1.7.0 org.apache.batik.pdf_1.6.0.v201105071520.jar->Now 1.7.0 poi uk.co.spudsoft.birt.emitters.excel_4.3.1.v201308301349.jar (bundled poi-ooxml-3.9-20121203.jar) org.apache.poi_3.9.0.v201303080712.jar ->May need to upgrade.
Hi Yulin, Thank you for the feedback. My apologies but I originally referred to the OSGi runtime, however I was actually scanning the RCP package. Since I used dependency checker to produce the 4.3.1 report, I ran it again against the 4.8 RCP package. The finding for derby was removed due to the upgrade you mentioned. However for the other libraries, there are still known vulnerabilities. Specifically: - axis This is appearing on the new report as version 1.4 under plugins\org.apache.axis_1.4.0.v201411182030\lib\axis.jar. That version has 3 published medium severity vulnerabilities. - batik The tool found multiple references to batik, between 1.7.0 and 1.9.0. All of these versions have registered vulnerabilities (one high severity in 1.9 and an additional high severity in 1.7.x) - poi As you noted this was not updated and remains at 3.9, which has 5 CVEs. So even if we upgrade to the latest version, it does not resolve the security issues. I am attaching a copy of the scan report. Thanks, Angela
Created attachment 277543 [details] BIRT 4.8 Dependency Check report
(In reply to Angela McCafferty from comment #5) > Hi Yulin, > > Thank you for the feedback. My apologies but I originally referred to the > OSGi runtime, however I was actually scanning the RCP package. Since I used > dependency checker to produce the 4.3.1 report, I ran it again against the > 4.8 RCP package. The finding for derby was removed due to the upgrade you > mentioned. However for the other libraries, there are still known > vulnerabilities. Specifically: > > - axis > This is appearing on the new report as version 1.4 under > plugins\org.apache.axis_1.4.0.v201411182030\lib\axis.jar. That version has 3 > published medium severity vulnerabilities. > > - batik > The tool found multiple references to batik, between 1.7.0 and 1.9.0. All > of these versions have registered vulnerabilities (one high severity in 1.9 > and an additional high severity in 1.7.x) > > - poi > As you noted this was not updated and remains at 3.9, which has 5 CVEs. > > So even if we upgrade to the latest version, it does not resolve the > security issues. I am attaching a copy of the scan report. > > Thanks, > Angela Hello Angel, Thanks for the reply. BIRT also depends on other projects to provide these 3P libraries. BIRT can only choose which version to use, but has no way to fix the problem in libraries. Most of these 3P libraries are from eclipse orbit project. The latest version BIRT can use is: https://download.eclipse.org/tools/orbit/downloads/drops/R20181128170323/. You can see all of them are latest. BIRT cannot fix them before eclipse orbit.
Angela, It will be helpful if you have recommendations on the versions of axis, batik and poi that address the vulnerabilities. Then Orbit could be requested to provide those versions. And then BIRT could build an updated package with those.
As Pradeep requested here are the recommended versions: Batik 1.10 https://www.cvedetails.com/vulnerability-list/vendor_id-45/product_id-4834/Apache-Batik.html POI 3.17 https://www.cvedetails.com/vulnerability-list/vendor_id-45/product_id-22766/Apache-POI.html Axis is problematic because it has been replaced by the Axis2 project and is no longer being developed. The last version of Axis is 1.4, which has vulnerabilities that will never be addressed. https://www.cvedetails.com/vulnerability-list/vendor_id-45/product_id-11016/Apache-Axis.html
Pradeep, If the library updates can be provided by Orbit, do you know how long it would take for the updated BIRT package to be made available? Thanks, Angela
These critical libraries upgrade need full testing. Other than that, here are some potential issues we encountered at the past: 1. The new libraries have class loading issue in OSGi. Like batik 1.9 upgrade, some batik jars depend on different version of other libraries, and these inconsistent may lead to linkage error. 2. New API are not backward compatible. We need to adjust these affected calls. 3. Orbit itself takes time to publish and need to verify by all other dependency projects. If all 3P libraries can be provided in good shape, BIRT side can finish in additional 3 month.
(In reply to Angela McCafferty from comment #10) > Pradeep, > > If the library updates can be provided by Orbit, do you know how long it > would take for the updated BIRT package to be made available? I see that Yulin has provided the ETA of updated BIRT package once Orbit has been updated. @Yulin, Thanks for providing the ETA. Good to know the team already evaluated the impact. Please initiate the process to get newer libraries added to Orbit. It needs to be initiated by the committers of the consuming project as it requires a few CQs to be created. Here is the process to follow: https://wiki.eclipse.org/Orbit/Adding_Bundles_to_Orbit The newer libs of Batik, POI and Axis2 are available on maven central (from where Orbit scripts fetch them). If you have questions on the process, please ask on orbit-dev@eclipse.org mailing list.
@Yulin, any update on adding the updated versions of the libraries to Orbit?
Usually, BIRT does not upgrade these orbit 3p libraries. The original authors will do that. If you can finish the orbit parts or ask the original authors to do, then we can start to integrate these libraries.
(In reply to Yulin Wang from comment #14) > Usually, BIRT does not upgrade these orbit 3p libraries. The original > authors will do that. > If you can finish the orbit parts or ask the original authors to do, then we > can start to integrate these libraries. As I explained in an earlier comment, Orbit libraries are to be updated by a component that consumes them as the process requires a new CQ to be created, which can be created only by committers as mentioned in comment 12.
As already mentioned, a BIRT committer must file the CQ. This is done on https://projects.eclipse.org/projects/birt/. Once the CQ is approved one has to file an ATO CQ (Add To Orbit) and after the approval, add it to Orbit. A possible alternative for having a BIRT committer do this, might be to ask the Eclipse legal team to do it. Wayne, any other options?
@Wayne, what are the options to get us towards a fix? Would the legal team be able to raise (and approve) the CQ to get the newer versions of the libs available in orbit? BIRT team has agreed to adopt them by making necessary source changes. We need to make progress here; it was reported 18 months ago.
(In reply to Pradeep Balachandran from comment #17) > @Wayne, what are the options to get us towards a fix? The assertion that somebody else needs to update the bundles in Orbit isn't correct. Anybody committer do that. So Eclipse BIRT committers absolutely can engage with the Orbit project to update them. Alternatively, some other committer can engage with Orbit to update those bundles. > Would the legal team > be able to raise (and approve) the CQ to get the newer versions of the libs > available in orbit? No. The project team needs to actually create the CQs and engage. The IP Team certainly cannot engage directly in Orbit or fix build scripts.
(In reply to Wayne Beaton from comment #18) > (In reply to Pradeep Balachandran from comment #17) > > @Wayne, what are the options to get us towards a fix? > > The assertion that somebody else needs to update the bundles in Orbit isn't > correct. Anybody committer do that. So Eclipse BIRT committers absolutely > can engage with the Orbit project to update them. The problem is filing the CQ, which only a BIRT committer can do. That's where we are blocked. If I recall correctly Pradeep talked to a BIRT committer and he asked whether Pradeep's team could file the CQs. Pradeep, correct me if I misunderstood things.
(In reply to Dani Megert from comment #19) > (In reply to Wayne Beaton from comment #18) > > (In reply to Pradeep Balachandran from comment #17) > > > @Wayne, what are the options to get us towards a fix? > > > > The assertion that somebody else needs to update the bundles in Orbit isn't > > correct. Anybody committer do that. So Eclipse BIRT committers absolutely > > can engage with the Orbit project to update them. > The problem is filing the CQ, which only a BIRT committer can do. That's > where we are blocked. Yes, that's where we are blocked. We need a committer from BIRT to initiate this. > If I recall correctly Pradeep talked to a BIRT committer and he asked whether > Pradeep's team could file the CQs. Pradeep, correct me if I misunderstood things. As per an earlier comment, Yulin from BIRT team was expecting someone else to get the new libraries to Orbit. Given the assertion from Wayne that the project team should create the CQ, we need BIRT team to initiate this. @Yulin please provide a time-line on when you will be able to adopt the new libraries, including getting the newer versions to orbit. Comment 12 has the necessary instructions.
(In reply to Dani Megert from comment #19) > (In reply to Wayne Beaton from comment #18) > > (In reply to Pradeep Balachandran from comment #17) > > > @Wayne, what are the options to get us towards a fix? > > > > The assertion that somebody else needs to update the bundles in Orbit isn't > > correct. Anybody committer do that. So Eclipse BIRT committers absolutely > > can engage with the Orbit project to update them. > The problem is filing the CQ, which only a BIRT committer can do. That's > where we are blocked. If I recall correctly Pradeep talked to a BIRT > committer and he asked whether Pradeep's team could file the CQs. Pradeep, > correct me if I misunderstood things. That's not true. Any eclipse committer can contribute to orbit project. Please help contribute these three libraries to orbit if you really want it to be resolved, and it can also benefit other projects. I would suggest you file separate 3 bugs to orbit and mark this to depend on these three. Again, this is not blocked by BIRT but orbit. Thanks, Yulin
(In reply to Yulin Wang from comment #21) > (In reply to Dani Megert from comment #19) > > (In reply to Wayne Beaton from comment #18) > > > (In reply to Pradeep Balachandran from comment #17) > > > > @Wayne, what are the options to get us towards a fix? > > > > > > The assertion that somebody else needs to update the bundles in Orbit isn't > > > correct. Anybody committer do that. So Eclipse BIRT committers absolutely > > > can engage with the Orbit project to update them. > > The problem is filing the CQ, which only a BIRT committer can do. That's > > where we are blocked. If I recall correctly Pradeep talked to a BIRT > > committer and he asked whether Pradeep's team could file the CQs. Pradeep, > > correct me if I misunderstood things. > > That's not true. > Any eclipse committer can contribute to orbit project. Yes, I know, anyone could contribute and an Orbit committer can merge it. BUT in order to add it we need a CQ from BIRT and that can only be submitted by a BIRT committer and not by any committer. So, if you can just create the CQ we can proceed with the real work.
(In reply to Yulin Wang from comment #21) > Again, this is not blocked by BIRT but orbit. With respect, this is blocked by the Eclipse BIRT project team's refusal to engage. Which, frankly, is the project team's prerogative. The Eclipse Orbit project is not blocking you. The way that Orbit works is that when a project needs a new version of a component, they engage with the Orbit project and work with them to get that new version into the Orbit repository. This process starts with the project team (BIRT) creating a project-specific CQ for the content and then having it moved into Orbit.
OK. I have submitted following CQs for you to move forward. CQ for poi 3.17 has been filed as: https://dev.eclipse.org/ipzilla/show_bug.cgi?id=19412. Now it's awaiting source code for approval. Could you attach source code here? Batik 1.10 contains a lot of sub-libraries. All of them have CQs. 4 of them including css, constants, i18n, util have already been added to latest orbit https://download.eclipse.org/tools/orbit/downloads/drops/R20190226160451/. Remaining libraries should be still ongoing. Regarding axis, it's still not clear which jar and which version will be added to orbit. Could you add more information about them?
Thank you Yulin! Appreciate you submitting the CQs to initiate the orbit process. Angela, could you please give a pointer to the sources of poi 3.17 and also clarify which axis jar is needed?
Yulin, The poi 3.17 source is available here: https://archive.apache.org/dist/poi/release/src/ Regarding Axis, is migrating to Axis2 an option? There is no secure version of Axis. Thanks, Angela
Yulin, Any thoughts on a possible Axis2 migration? The package is available here: http://axis.apache.org/axis2/java/core/download.html And a migration guide is here: http://axis.apache.org/axis2/java/core/docs/migration.html Thanks, Angela
(In reply to Yulin Wang from comment #24) > > Regarding axis, it's still not clear which jar and which version will be > added to orbit. Could you add more information about them? Yulin, Could you please open CQ once again and attach the source code for the three libs, including Axis2 as per the info Angela provided in comment #27? The CQ mentioned in comment #24 has been auto-closed due to inactivity.
(In reply to Pradeep Balachandran from comment #28) > (In reply to Yulin Wang from comment #24) > > > > Regarding axis, it's still not clear which jar and which version will be > > added to orbit. Could you add more information about them? > > Yulin, Could you please open CQ once again and attach the source code for > the three libs, including Axis2 as per the info Angela provided in comment > #27? > > The CQ mentioned in comment #24 has been auto-closed due to inactivity. The CQ https://dev.eclipse.org/ipzilla/show_bug.cgi?id=19412 is used for review poi 3.17 source code. But I don't find source code for 3.17 in https://archive.apache.org/dist/poi/release/src/. Maybe a different version?
Please disregard #29. I find 3.17 and uploaded to CQ for code review.
(In reply to Yulin Wang from comment #30) > Please disregard #29. I find 3.17 and uploaded to CQ for code review. Thank you Yulin. Please watch the CQ to ensure it is not waiting for anything. Once this is clear, I presume we can move faster on this.
Yulin, CQ https://dev.eclipse.org/ipzilla/show_bug.cgi?id=19412 is now resolved. Could you provide an ETA for an updated BIRT package? Thanks!
Yulin, many teams are waiting on a resolution for the security vulnerabilities. Could you help provide an updated BIRT package with the new libraries? Any ETA? Thanks!
(In reply to Yulin Wang from comment #30) > Please disregard #29. I find 3.17 and uploaded to CQ for code review. The CQ timed out and was automatically withdrawn before you uploaded the attachment. When this happens, please send a note to emo-ip-team@eclipse.org to get them to reopen the CQ. I've asked the IP Team to reopen the CQ and put it into their work queue. FWIW, under ideal conditions the IP Team will notice when this happens, but if it takes them more than around a day to do so, send them a note.
I've removed the committer-only flag per the Eclipse Security Policy's requirement that we disclose (we're a well over the three month maximum).
The CQ is just reviewed by IP team. (Sorry I didn't realize it was previously closed automatically) But now it looks like it doesn't pass the test. Waiting for IP team's recommendation of the next step.
(In reply to Yulin Wang from comment #36) > The CQ is just reviewed by IP team. (Sorry I didn't realize it was > previously closed automatically) > But now it looks like it doesn't pass the test. Waiting for IP team's > recommendation of the next step. It hasn't passed the test *yet*. The automatic scanner detected some anomalies that the IP Team needs to investigate.
(In reply to Wayne Beaton from comment #37) > (In reply to Yulin Wang from comment #36) > > The CQ is just reviewed by IP team. (Sorry I didn't realize it was > > previously closed automatically) > > But now it looks like it doesn't pass the test. Waiting for IP team's > > recommendation of the next step. > > It hasn't passed the test *yet*. The automatic scanner detected some > anomalies that the IP Team needs to investigate. The IP team responded and requested your input.
(In reply to Pradeep Balachandran from comment #31) > (In reply to Yulin Wang from comment #30) > > Please disregard #29. I find 3.17 and uploaded to CQ for code review. > > Thank you Yulin. Please watch the CQ to ensure it is not waiting for > anything. Once this is clear, I presume we can move faster on this. Hi Pradeep, It looks like the source code you provided cannot pass the IP team's review. The reason is "It appears you have likely provided source for the entire POI project and not just the project's binary requirements?? We are seeing incompatible license hits in content that you likely do not require such as examples, test, data, spreadsheets, etc. Therefore, rather than investigating further, we ask if you can narrow the scope and provide a new attachment." Could you attach a new one to meet the requirement? Thanks, Yulin
(In reply to Yulin Wang from comment #39) > (In reply to Pradeep Balachandran from comment #31) > > (In reply to Yulin Wang from comment #30) > > > Please disregard #29. I find 3.17 and uploaded to CQ for code review. > > > > Thank you Yulin. Please watch the CQ to ensure it is not waiting for > > anything. Once this is clear, I presume we can move faster on this. > > Hi Pradeep, > It looks like the source code you provided cannot pass the IP team's review. I did not provide the source code. Angela provided it. > > Could you attach a new one to meet the requirement? > Angela, could you please provide the source for just the library as per the suggestion from the IP team in the earlier comment from Yulin? If you have questions, please send email to emo-ip-team@eclipse.org for clarification, referring to this bug and copy Yulin.
Thanks Pradeep, I will email the IP team to confirm the requirement. Yulin, Dependency Checker originally found two references to POI: 1. uk.co.spudsoft.birt.emitters.excel_4.3.1.v201308301349.jar (bundled poi-ooxml-3.9-20121203.jar) 2. org.apache.poi_3.9.0.v201303080712.jar Does the CQ only apply to the second or can the Spudsoft emitter also be updated? Thanks, Angela
(In reply to Angela McCafferty from comment #41) > Thanks Pradeep, I will email the IP team to confirm the requirement. > > Yulin, > > Dependency Checker originally found two references to POI: > 1. uk.co.spudsoft.birt.emitters.excel_4.3.1.v201308301349.jar (bundled > poi-ooxml-3.9-20121203.jar) > 2. org.apache.poi_3.9.0.v201303080712.jar > > Does the CQ only apply to the second or can the Spudsoft emitter also be > updated? > > Thanks, > Angela The source code for review is: https://archive.apache.org/dist/poi/release/src/poi-src-3.17-20170915.zip
Regarding uk.co.spudsoft.birt.emitters.excel, it is using the poi as a library (now from lib jar but soon from plugin dependency by https://github.com/eclipse/birt/pull/551/files). So once the poi is upgraded, the excel emitter will use that one automatically.
Yulin and Pradeep, In comment 40, Pradeep suggested to "provide the source for just the library". I am unsure exactly what that means but I took a stab at it. I extracted the contents of poi-src-3.17-20170915.zip\poi-3.17\src\java folder, re-zipped it, and attached that to the case. The content corresponds to the structure of poi-3.17.jar so hopefully this is what is needed. If not, who would be able to provide additional details? I did also email the IP team but have not heard back yet. Thanks!
Created attachment 279528 [details] Apache poi 3.17 source
(In reply to Angela McCafferty from comment #45) > Created attachment 279528 [details] > Apache poi 3.17 source I just attached this for IP team to review. I think they just want to narrow the scope of the source code to include the library only.
The IP team has approved the license review. Once it is included in latest orbit repositories, BIRT can upgrade it right away.
(In reply to Yulin Wang from comment #47) Yulin, Good news, thanks! What is the process for including in Orbit? Is there anything further I need to do at this point? Angela
@Yulin, Are you waiting on someone to get these into the orbit? What help do you need to get to closure on this?
(In reply to Pradeep Balachandran from comment #49) > @Yulin, Are you waiting on someone to get these into the orbit? What help do > you need to get to closure on this? Yes, I just checked latest orbit: https://download.eclipse.org/tools/orbit/downloads/drops/R20190827152740/. I don't find poi is updated to 3.17.
There's no automated process that updates Orbit once a bundle is approved by the IP team. Someone with Orbit commit rights must contribute it to Orbit.
Yulin, could you please attach the right set of libraries here so that we can have someone with Orbit commit rights to update the Orbit repository?
(In reply to Pradeep Balachandran from comment #52) > Yulin, could you please attach the right set of libraries here so that we > can have someone with Orbit commit rights to update the Orbit repository? Thanks for helping on this. The IP approved source code is https://archive.apache.org/dist/poi/release/src/poi-src-3.17-20170915.zip You can use this binary jar: https://archive.apache.org/dist/poi/release/bin/poi-bin-3.17-20170915.zip or build it from source code.
Yulin, Please call out the names of the libraries (including version) or link to them (if not in the zip). As per comment 4, there are four libraries. We need to make it super easy for whoever is volunteering to update the Orbit repo with new libraries.
I've just created bug 551132 for a vulnerability in the used dom4j 1.6.1 before noticing that dom4j also listed in the DependencyCheck report of attachment 277543 [details] but not mentioned in the description here. Sorry for that, maybe it makes more sense to cover this here and close bug 551132, so I'm mentioning it: dom4j 1.6.1 CVE-2018-1000632 Details https://nvd.nist.gov/vuln/detail/CVE-2018-1000632 Is BIRT vulnerable to this XML injection through dom4j? Can BIRT upgrade to dom4j 2.1.1?
(In reply to Yulin Wang from comment #53) > (In reply to Pradeep Balachandran from comment #52) > > Yulin, could you please attach the right set of libraries here so that we > > can have someone with Orbit commit rights to update the Orbit repository? > > Thanks for helping on this. > The IP approved source code is > https://archive.apache.org/dist/poi/release/src/poi-src-3.17-20170915.zip > You can use this binary jar: > https://archive.apache.org/dist/poi/release/bin/poi-bin-3.17-20170915.zip or > build it from source code. Yulin, Pradeep requested that the updated poi be attached to the bug. I can do that but from your comment I am unclear which version to attach. Is the binary sufficient?: https://archive.apache.org/dist/poi/release/bin/poi-bin-3.17-20170915.zip Thanks, Angela
Yes.(In reply to Angela McCafferty from comment #56) > (In reply to Yulin Wang from comment #53) > > (In reply to Pradeep Balachandran from comment #52) > > > Yulin, could you please attach the right set of libraries here so that we > > > can have someone with Orbit commit rights to update the Orbit repository? > > > > Thanks for helping on this. > > The IP approved source code is > > https://archive.apache.org/dist/poi/release/src/poi-src-3.17-20170915.zip > > You can use this binary jar: > > https://archive.apache.org/dist/poi/release/bin/poi-bin-3.17-20170915.zip or > > build it from source code. > > Yulin, > > Pradeep requested that the updated poi be attached to the bug. I can do that > but from your comment I am unclear which version to attach. Is the binary > sufficient?: > https://archive.apache.org/dist/poi/release/bin/poi-bin-3.17-20170915.zip > > Thanks, > Angela I think so.
Created attachment 280165 [details] Apache poi 3.17 binary distribution Attaching the updated poi library to be committed to Orbit repository.
@Roland, I don't see nay Orbit recipes for org.apache.poi.* What will be the process to upgrade org.apache.poi, org.apache.poi.ooxml and org.apache.poi.ooxml.schemas jars from 3.9 to 3.17 ? The src and jars are attached here and the CQ is also approved : https://dev.eclipse.org/ipzilla/show_bug.cgi?id=19412
Yulin, I noticed that the earlier CQ only covers POI. Please open CQs for Axis2 (since it is not in orbit) and Batik (if a newer version than the one orbit is required).
(In reply to Sarika Sinha from comment #59) > @Roland, > I don't see nay Orbit recipes for org.apache.poi.* > > What will be the process to upgrade org.apache.poi, org.apache.poi.ooxml > and org.apache.poi.ooxml.schemas jars from 3.9 to 3.17 ? > > The src and jars are attached here and the CQ is also approved : > https://dev.eclipse.org/ipzilla/show_bug.cgi?id=19412 Assuming the CQ(s) cover the 3 bundles, we could bundle them like any other orbit-recipes project. They are maven artifacts [1]. Someone should also check that the metadata is mostly the same. Once we've added 3.17, I can go remove them from the old (CVS/cruisecontrol) repository. This is a good thing as we should always be striving to reduce the size of that old repository and slowly have everything migrated over to orbit-recipes. [1] https://search.maven.org/search?q=g:org.apache.poi
(In reply to Pradeep Balachandran from comment #60) > Yulin, I noticed that the earlier CQ only covers POI. Please open CQs for > Axis2 (since it is not in orbit) and Batik (if a newer version than the one > orbit is required). I don't see org.apache.axis2 in orbit download site like https://download.eclipse.org/tools/orbit/downloads/drops/I20190927200341/ I can see it in maven repo.
Sarika / Roland - Could you please help in getting the IP certified POI libraries to the Orbit repository? Yulin - As I mentioned earlier, please open CQs for Axis2 and new Batik versions so that those could be added to the Orbit repository.
(In reply to Pradeep Balachandran from comment #63) > Sarika / Roland - Could you please help in getting the IP certified POI > libraries to the Orbit repository? > > Yulin - As I mentioned earlier, please open CQs for Axis2 and new Batik > versions so that those could be added to the Orbit repository. We have latest Batik 1.11 in Orbit, so we need a CQ for Axis2. I will be working on creating the initial Orbit recipe for POI.
Thank you Sarika, for stepping in, to add POI libraries to Orbit. @Yulin - Please open a CQ for Axis2 and update here once that CQ is approved.
Orbit has 3 jars for poi: org.apache.poi 3.9.0 org.apache.poi.ooxml 3.9.0 org.apache.poi.ooxml.schemas 3.9.0 CQ was taken for only first one. The attached source also includes only the content from first jar.
Thanks Sarika for the heads-up. @Angela - Can you look at the previous comment and confirm whether the two additional libraries need to be updated as well? If so, please attach those libraries, and request Yulin to open CQ for those.
New Gerrit change created: https://git.eclipse.org/r/151507
(In reply to Pradeep Balachandran from comment #67) > Thanks Sarika for the heads-up. > > @Angela - Can you look at the previous comment and confirm whether the two > additional libraries need to be updated as well? If so, please attach those > libraries, and request Yulin to open CQ for those. I'm attaching these source files: poi-ooxml-3.17-sources.jar ooxml-schemas-1.3-sources.jar And these binaries: poi-ooxml-3.17.jar poi-ooxml-schemas-3.17.jar Sarika, can you confirm that this is what is needed? If so, Yulin, can you create the CQ? Thanks, Angela
Created attachment 280407 [details] Apache poi-ooxml 3.17 source
Created attachment 280408 [details] Apache poi-ooxml-schemas 1.3 source
Created attachment 280409 [details] Apache poi-ooxml-schemas 3.17
Created attachment 280410 [details] Apache poi-ooxml 3.17 binary
(In reply to Angela McCafferty from comment #69) > (In reply to Pradeep Balachandran from comment #67) > > Thanks Sarika for the heads-up. > > > > @Angela - Can you look at the previous comment and confirm whether the two > > additional libraries need to be updated as well? If so, please attach those > > libraries, and request Yulin to open CQ for those. > > I'm attaching these source files: > poi-ooxml-3.17-sources.jar > ooxml-schemas-1.3-sources.jar > > And these binaries: > poi-ooxml-3.17.jar > poi-ooxml-schemas-3.17.jar > > Sarika, can you confirm that this is what is needed? > > If so, Yulin, can you create the CQ? > > Thanks, > Angela Yes, we will need the latest , i.e 4.1.1 version of these jars.
Created attachment 280424 [details] Apache poi 4.1.1 source Zip that includes 3 jars: poi-4.1.1-sources.jar ooxml-schemas-1.4-sources.jar poi-ooxml-4.1.1-sources.jar
Created attachment 280425 [details] Apache 4.1.1 binary distribution Zip that includes three jars: poi-4.1.1.jar poi-ooxml-4.1.1.jar poi-ooxml-schemas-4.1.1.jar
(In reply to Sarika Sinha from comment #74) > (In reply to Angela McCafferty from comment #69) > > I'm attaching these source files: > > poi-ooxml-3.17-sources.jar > > ooxml-schemas-1.3-sources.jar > > > > And these binaries: > > poi-ooxml-3.17.jar > > poi-ooxml-schemas-3.17.jar > > > > Sarika, can you confirm that this is what is needed? > > > > If so, Yulin, can you create the CQ? > > > > Thanks, > > Angela > > Yes, we will need the latest , i.e 4.1.1 version of these jars. I attached the files for 4.1.1. I grouped them into two zip files, let me know if you need a different format. Thanks, Angela
Thank you Angela. @Yulin, could you please open the CQs for the additional POI libraries as well as Axis2? Without CQ approval, the libraries cannot get into orbit repository. Please update here once you get the CQ approval.
@Yulin, could you please update us on the opening of the CQs for the additional POI libraries as well as Axis2? Thanks a lot.
@Yulin, request your help to close this. Please open CQs for the additional POI libraries as well as Axis2. We have Orbit committers standing by to add them to Orbit repository as soon as CQs are done. @Wayne, if BIRT team is not able to help, do you have any recommendation on how to take this forward?
> @Wayne, if BIRT team is not able to help, do you have any recommendation on > how to take this forward? Connect with the Eclipse Orbit Project leads (via the Orbit dev list). With the recent changes to the IP Policy, changes to the Orbit process will likely follow; maybe this situation can expedite those changes.
Yulin has informed EMO via email that he is no longer working on the Eclipse BIRT project. Somebody else from BIRT will need to step up. Virgil and Mihail, can you help?
Wayne, Since Yulin is no longer part of the project, what remains to be done to get the CQs approved and libraries updates? I can work with our team locally to get this done. -John
> Since Yulin is no longer part of the project, what remains to be done to get > the CQs approved and libraries updates? I can work with our team locally to > get this done. We need a committer from the project team to engage in the Eclipse Orbit process: https://www.eclipse.org/orbit/overview.php For help, connect directly with the Orbit project dev list: https://dev.eclipse.org/mailman/listinfo/orbit-dev I don't see that you have committer status at this moment, John. Do you have access to project committers?
I will be looking into this. I need to add the POI 4.1.1 into a new CQ right? with the attach source or distribution https://dev.eclipse.org/ipzilla/show_bug.cgi?id=19412 This one is obsolete as it is on POI 3.7
(In reply to ShiHeng Guan from comment #85) > I will be looking into this. I need to add the POI 4.1.1 into a new CQ > right? No. The IP Policy was recently changed; we do not require CQs for content for which we have reliable, trusted license information. We have trusted license information about this library, so no CQ is required.
But I couldn't find 4.1.1 version to piggy back. I will look for the policy, but how is the process now to update into the new apache POI? Thanks
Sorry, meant to send this off myself now that I have the build process working with Orbit in-line. The current process is to send a message to the Eclipse Orbit Mailing list making the request. Just join the Orbit committer mailing list, and then send the request.
The IP Policy changed in October 2019. We've been working on rolling it out, but we're not quite there yet. The IP Policy has been updated, but most of our processes are still ramping up. The short version is that we now have two trusted sources of license information: our IPzilla database and ClearlyDefined. The particular version of POI that you want to use is in the ClearlyDefined database. https://clearlydefined.io/definitions/maven/mavencentral/org.apache.poi/poi/4.1.1 There's more information here: https://waynebeaton.wordpress.com/2019/11/13/reviewing-third-party-content/ This is still a work in progress. We're updating our documentation and supporting processes as quickly as we can. Note that we'll also update the Orbit processes to not require a CQ; that should hopefully be done in time for the next simultaneous release in June.
So for the update, we just need to send the request through the mailing list? Correct?
(In reply to John Ward from comment #90) > So for the update, we just need to send the request through the mailing > list? Correct? In my attempt to optimize, I've probably just confused things. The IP Policy has changed, but we're still in the middle of rolling out the changes that support it, including how we work with Orbit. Connect with the Orbit project and ask their advice. If they say that you need to create a CQ, then create a CQ.
New Gerrit change created: https://git.eclipse.org/r/161161
Gerrit change https://git.eclipse.org/r/161161 was merged to [master]. Commit: http://git.eclipse.org/c/orbit/orbit-recipes.git/commit/?id=03e252f66923172c5792069a5300b7de898e0f0f
Gerrit change https://git.eclipse.org/r/151507 was merged to [master]. Commit: http://git.eclipse.org/c/orbit/orbit-recipes.git/commit/?id=9456a4b584ec800c2dd5c72ece186a528cb26c7a