IBM i Global

 View Only
Expand all | Collapse all

ICU (QICU library) on the system is too obsolete despite being a public user facing API

  • 1.  ICU (QICU library) on the system is too obsolete despite being a public user facing API

    Posted Mon May 20, 2024 05:46 AM

    Hello...

    needing to use a library for a project to properly handle some tasks involving unicode string processing for a B2B system, I wanted to leverage the API enlisted here from RPG

    https://www.ibm.com/docs/en/i/7.5?topic=interfaces-api-finder

    as "International Components for Unicode APIs"

    ICU is a library present in a lot of systems to properly handle unicode processing (i.e. normale decomposition etc.etc.).

    But, to my surprise, on our up to date V7R4, the SRVPGMs present in the QICU library are more than 10 years old (!) , the last one I can see is one implementing the ICU 4.0 version .

    Despite being a public API of the system, it is lacking 15 years of quality features and improvement, as you can imagine, also security problems occurred in time .... the ICU4C code had also nasty (overruns, overflows... ) and public security issues (CVE) as can be seen here https://www.cvedetails.com/vulnerability-list/vendor_id-17477/Icu-project.html

    Despite I insist that a public API, publicly exposed in the documentation, should be kept up to date by the vendor with PTFs, one can as a last resort in theory compile the library himself, using the pointers here

    https://unicode-org.github.io/icu/userguide/icu4c/build.html#how-to-build-and-install-on-the-ibm-i-family-ibm-i-i5os-os400

    BUT

    the tools used in such instructions refer to the IFS folder (probably containing the icc compiler...) called 

    /QIBM/ProdData/DeveloperTools/

    that are now obsolete, and replaced by a product than itself is already obsolete.

    How to properly obtain or compile an up to date ICU on IBMi (a task that maybe in other systems and OSes would have taken 5 minutes...) using a supported workflow and resolve this Kafkaesque situation?

    As a customer I've already 

    • contacted support (that cannot solve or update the libraries but at least contacted security team apparently)
    • contacted VAR on how to obtain the eventual compiler to build the public ICU project (no answer)
    • logged an "idea" on the "ideas" site (yes apparently for IBM security fixes of a public API are also an "idea", maybe in their ideal world ; ) )

    For a OS involved geared mainly in business processing, B2C/B2B, EDI, etc. is astonishing not having a proper library for unicode tasks.



    ------------------------------
    --ft
    ------------------------------


  • 2.  RE: ICU (QICU library) on the system is too obsolete despite being a public user facing API

    Posted Tue May 21, 2024 05:17 AM
    Edited by 英幸 矢作 Tue May 21, 2024 05:18 AM

    > But, to my surprise, on our up to date V7R4, the SRVPGMs present in the QICU library are more than 10 years old (!) 

    The real reason is unknown, but it may be that the "IBM Tools for Developers for i5/OS" (5799-PTL) on which the build is based was not supported.

    This PRPQ is already withdrawn.

    https://www.ibm.com/common/ssi/ShowDoc.wss?docURL=/common/ssi/rep_rp/7/ENUSP84487/index.html&request_locale=en

    > For a OS involved geared mainly in business processing, B2C/B2B, EDI, etc. is astonishing not having a proper library for unicode tasks.

    Aside from security issues, the ICU project is also considering discontinuing support for the EBCDIC platform.

    https://unicode-org.atlassian.net/browse/ICU-21672

    Personally, I would like IBM to contribute to the ICU project in an organized way.



    ------------------------------
    Hideyuki Yahagi
    ------------------------------



  • 3.  RE: ICU (QICU library) on the system is too obsolete despite being a public user facing API

    Posted Tue May 21, 2024 12:32 PM

    Yes, we are not speaking about a "minor" library here, it is a fundamental library that is the defacto standard to handle unicode tasks, integrated in many systems.

    IBM should respond to this, putting the customer in a position to use a publicly documented API in a full ILE environment (i.e. bindable SRVPGM) without too much hassle on par with other systems, it's not acceptable not keeping such library up to date and not providing an alternative solution.



    ------------------------------
    --ft
    ------------------------------