GMT_DATA_SERVER Env var is not working

[joa-quim]

With the black down of the Hawaii server (Forum is down) many CI tests fail, all GMT.jl tests fail too.
Tried to
set (GMT_DATA_SERVER china)
but no luck, and local runs fail with

C:\v>grdinfo @earth_relief_01d_p
unknown [ERROR]: Bad record counter in file C:/Users/j/.gmt/gmt_data_server.txt
unknown [ERROR]: Deleting C:/Users/j/.gmt/gmt_data_server.txt so it can get regenerated - please try again
grdinfo [ERROR]: Unable to open file C:/Users/j/.gmt/gmt_data_server.txt
grdinfo [ERROR]: Remote download is currently deactivated
grdinfo [ERROR]: Unable to obtain remote file @earth_relief_01d_p
grdinfo [ERROR]: Must specify one or more input files

[joa-quim]

Found part of the problem. When one do
set (GMT_DATA_SERVER china)
it tries to download http://china.generic-mapping-tools.org/gmt_data_server.txt, which fails and returns some html file. Setting the explicit address, works. That is works
set (GMT_DATA_SERVER https://mirrors.ustc.edu.cn/gmtdata/)

[joa-quim]

I don't know how to solve this. @redyank is this related to what you want to report?

[redyank]

No, this is not related to the current server outage. The issue I found is a security vulnerability (stack-based buffer overflow) caused by missing input length validation in gmt_remote_dataset_id.

[joa-quim]

Was not referring to the sever outage but to the GMT_DATA_SERVER variable issue.
From your description the vulnerability, once identified, should not be difficult to fix. Please provide more details.

[redyank]

Understood. I have already reproduced the stack-based buffer overflow using AddressSanitizer (ASan) and identified the problematic code in src/gmt_remote.c.

To ensure a responsible disclosure, I will email you the full technical report, including the ASan logs and a minimal PoC script, right away. Please check your inbox shortly.

[seisman]

Found part of the problem. When one do set (GMT_DATA_SERVER china) it tries to download http://china.generic-mapping-tools.org/gmt_data_server.txt, which fails and returns some html file. Setting the explicit address, works. That is works set (GMT_DATA_SERVER https://mirrors.ustc.edu.cn/gmtdata/)

It's likely some protection or misconfiguration on the USTC mirror. Other mirrors may have the same problem which resulted in the issue report in GenericMappingTools/gmtserver-admin#290.

Perhaps we should always recommend using the actual URLs rather than relying on the aliases?