Skip to content

Conversation

@dkjsone
Copy link
Contributor

@dkjsone dkjsone commented Oct 17, 2025

A total of 8 vulnerabilities were fixed, including 5 integer overflows, 2 division-by-zero crashes, and 1 null pointer crash.

WardF and others added 30 commits December 18, 2024 16:17
Update upload-artifact/download-artifact for github actions
Fix out-of-tree builds generating netcdf_json.h and netcdf_proplist.h
Clean up a couple small things while I'm looking at them.
DennisHeimbigner and others added 15 commits October 11, 2025 18:47
## Primary Changes
1. The ncdap_test/test_manyurls.c build in ncdap_test/Makefile.am caused some makefile warnings. These were fixed.
2. Make the test program ncdap_test/test_manyurls.c be operable.
3. After 1 and 2, it turns out that the test case is probably useless, so disable it.

## Secondary Changes
1. Fix the fact that the --enable-dap-long-tests option was not generating a corresponding NETCDF_ENABLE_DAP_LONG_TESTS flag in config.h.
2. Add NETCDF_ENABLE_DAP_LONG_TESTS to config.h.cmake.in to make it visible.
3. Discovered and fixed an obscure error in libdispatch/nclist.c function nameed nclistsetalloc.
4. Add support for CURLOPT_VERBOSE (as an environment variable) to libsrc/httpio.c.
re: Issue Unidata#3184

When ncdump attempts to find a dimension's Fully Qualified Name (FQN),
it uses a two step process.
1. Search up the group tree starting at the group in which the dimension the referenced.
2. If not found, then do a breadth first search of the whole group tree looking for the dimension.

Once located, a FQN is constructed with respect to the group in which the dimension was found.

It turns out there was a bug in the ncdump function "searchgroupdim" such that it always returned the top level group as the one containing the dimension.
This, of course is erroneous for nested dimension.

So the "searchgroupdim" function was fixed to properly fail if the dimension was not actually in the root group.
Fix bug in ncdump when printing dimension FQN
Fix the problems around ncdap_test/test_manyurls.c.
@CLAassistant
Copy link

CLAassistant commented Oct 17, 2025

CLA assistant check
Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you all sign our Contributor License Agreement before we can accept your contribution.
4 out of 5 committers have signed the CLA.

✅ WardF
✅ Dave-Allured
✅ dkjsone
✅ DennisHeimbigner
❌ johnwparent
You have signed the CLA already but the status is still pending? Let us recheck it.

Copy link
Collaborator

@DennisHeimbigner DennisHeimbigner left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This line and similar lines use size_t as a constant, but it fails in many cases.
What is the supposed value of size_t as a constant?

#define SIZE_MAX ((size_t)-1)

@DennisHeimbigner
Copy link
Collaborator

Can you please annotate the code changes to indicate what error they are fixing?

@dkjsone
Copy link
Contributor Author

dkjsone commented Oct 18, 2025

This line and similar lines use size_t as a constant, but it fails in many cases. What is the supposed value of size_t as a constant?

#define SIZE_MAX ((size_t)-1)

(size_t)-1 is used to obtain the platform-independent maximum value of size_t. On 32-bit systems, it is 0xFFFFFFFF, and on 64-bit systems, it is 0xFFFFFFFFFFFFFFFF.
Initially, I did not define this macro, and during Checks, the macOS platform encountered an issue of the macro being undefined. Therefore, I added this macro definition.

@dkjsone
Copy link
Contributor Author

dkjsone commented Oct 18, 2025

Can you please annotate the code changes to indicate what error they are fixing?

The changes I made to the code are relatively minor and quite similar, pertaining to routine security checks. I believe comments may not be strictly necessary in this case.
I have provided a detailed description of the issue and the reproduction method in this link. If there are any questions regarding the vulnerability, you can refer to this link for clarification.
https://support.unidata.ucar.edu/tickets/view/TSP-8629412

@WardF
Copy link
Member

WardF commented Oct 23, 2025

Hi @dkjsone, thanks for submitting this. I'm reviewing it now as well. In the meantime, do you mind accepting the CLA here so that we can clear that 'pending check'? Thanks!

@dkjsone
Copy link
Contributor Author

dkjsone commented Oct 24, 2025

Sorry, my mistake — I'm going to close this one and start over with a new pull request.

@dkjsone dkjsone closed this Oct 24, 2025
@dkjsone dkjsone deleted the bugfix branch October 24, 2025 08:45
@dkjsone
Copy link
Contributor Author

dkjsone commented Oct 24, 2025

Please review this new pull request.
#3191

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.