Replies: 2 comments 1 reply
-
This is related to #1037 |
Beta Was this translation helpful? Give feedback.
-
This suggestion is an very good suggestion. We are also use for our integrated version only the core functions of the OSGI-version without standard-parameter-viewer I don't know if it is a so good idea to remove some components e.g. on the OSGI-version so you could get complications during the runtime caused by missing objects/classes etc.. If there somebody which could support this idea this would be very appreciated. One comment to the full version, currently we use the full framwork for our develoment process based on the eclipse integration. |
Beta Was this translation helpful? Give feedback.
-
In our application, BIRT integration is done with BIRT Runtime and the RE API as described in the Wiki page.
We don't need the example report viewer: We don't show the report output in the browser, we don't need the browser for parameter input dialogs.
As can be seen in #965, many of the vulnerabilities are related to the web viewer in some way (Jetty, Prime Faces, Servlet API) and some of them are related to the Derby database.
Despite Steve Schafer's hard work, some vulnerabilities will always remain or new ones will join.
In our case (to the best of my knowledge) all of the existing vulnerabilities are related to features that we do not use at all.
But IT departments perform automatic scans of installed software. These scans usually just find a JAR file which is known to be vulnerable and complain about it. It it hard to explain (again and again) that our software is not affected by those vulnerabilities.
So we could avoid those discussions simply by just not have these JAR files installed.
Of course we could do trial and error - removing those files inside ReportEngine/lib which we think are not needed.
But I think it would make more sense to create kind of a "minimal runtime" artifact.
Is that feasible? And if so, can you give me some pointers?
Beta Was this translation helpful? Give feedback.
All reactions