On Thu, 2023-02-02 at 05:13 -0800, Jeff Davis wrote: > As a project, do we want to nudge users toward ICU as the collation > provider as the best practice going forward? One consideration here is security. Any vulnerability in ICU collation routines could easily become a vulnerability in Postgres. I looked at these lists: https://www.cvedetails.com/vulnerability-list/vendor_id-17477/Icu-project.html https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=icu https://unicode-org.atlassian.net/issues/?jql=labels%20%3D%20%22security%22 https://unicode-org.atlassian.net/issues/?jql=labels%20%3D%20%22was_sensitive%22 Here are the recent CVEs: CVE-2021-30535 https://unicode-org.atlassian.net/browse/ICU-21587 CVE-2020-21913 https://unicode-org.atlassian.net/browse/ICU-20850 CVE-2020-10531 https://unicode-org.atlassian.net/browse/ICU-20958 But there are quite a few JIRAs that look concerning that don't have a CVE assigned: 2021 https://unicode-org.atlassian.net/browse/ICU-21537 2021 https://unicode-org.atlassian.net/browse/ICU-21597 2021 https://unicode-org.atlassian.net/browse/ICU-21676 2021 https://unicode-org.atlassian.net/browse/ICU-21749 Not sure which of these are exploitable, and if they are, why they don't have a CVE. If someone else finds more issues, please let me know. The good news is that the Chrome/Chromium projects are actively finding and reporting issues. I didn't look for comparable information about glibc, but I would guess that exploitable memory errors in setlocale/strcoll are very rare, otherwise it would be a security disaster for many projects. -- Jeff Davis PostgreSQL Contributor Team - AWS
pgsql-hackers by date:
Соглашаюсь с условиями обработки персональных данных
