Apache Axis Should Be Replaced by Axis 2 Due to Multiple CVEs and EOL

[galacticgumshoe]

This is kind of a re-opening of issue #240 from last year where a high CVE was opened against Axis 1 library CVE-2019-0227. A new critical CVE has been opened against the Axis 1 library: CVE-2023-40743. I had attempted to follow the advice given in #240 and use the dfp-appengine, but found too many breaking changes in using it that I'm forced to continue leveraging dfp-axis. Even the latest 5.2.0 release continues to utilize Axis 1.4. Can you please consider upgrading to Axis 2?

[christopherseeley]

Thanks for raising this. I took a look at CVE-2023-40743. This library does not use the impacted Service.getService function. It creates service clients from descriptors. For example, here is where the LineItemService stub gets instantiated.

The upgrade to Axis 2 has a number of breaking changes as well, which is why I recommended dfp-appengine. Most of the changes are using Lists instead of Arrays. Are there missing features or other blockers for dfp-appengine?

[galacticgumshoe]

Functionally, I had to make these changes:

• Replace import statements containing com.google.api.ads.admanager.axis with com.google.api.ads.admanager.jaxws
• Replace all Exception class names with ones that had the suffix _Exception. In other words, the class ApiException in axis became ApiException_Exception in app engine
• Responses were Lists instead of Arrays.
• Responses no longer used primitive types, eg. long[] in axis but List<Long> in app engine
• PQL StatementBuilder had problems with accepting .withBindVariableValue() so I ended up having to do string munging without the use of bind variables.

I had rolled all of this to my production environment, and things worked great when testing. But over time we ended up seeing a higher number of failed calls and timeouts running on dfp-appegine. So I ended up reverting the whole thing back to fix reliability and stability.