GeezerVison is showing github.com — Upgrade bundled Expat to 2.8.2 (e.g. for the fix to CVE-2026-56132 and 12 others) · Issue #152216 · python/cpython
Upgrade bundled Expat to 2.8.2 (e.g. for the fix to CVE-2026-56132 and 12 others) #152216Activityzainnadeem786 commented on Jun 25, 2026 Hi @hartwork @StanFromIreland
I can take a look at this and prepare a focused PR if no one else is already working on it.
I checked the previous Expat 2.8.1 update pattern from gh-149698 / gh-149699 and started comparing the bundled 2.8.1 copy with upstream 2.8.2.
From the initial investigation, this looks like a focused vendoring update involving the refreshed Expat sources, the new upstream files mentioned here, SBOM metadata, and a Security NEWS entry while preserving CPython’s local Expat configuration and symbol namespacing.
I’ll validate the update with the focused XML/pyexpat test suite before opening a PR. StanFromIreland commented on Jun 25, 2026 I've assigned myself this, please check such things in the future. changed the title [-][security] Please upgrade bundled Expat to 2.8.2 (e.g. for the fix to CVE-2026-56132 and 12 others)[/-] [+]Upgrade bundled Expat to 2.8.2 (e.g. for the fix to CVE-2026-56132 and 12 others)[/+] on Jun 25, 2026cdce8p commented on Jul 13, 2026
Ok, it's because cpython's non-debug build turns on -Wunreachable-code - this results in warnings from both AppleClang and clang. It would be possible to disable -Wunreachable-code-fallthrough specifically.
Should this be added to xmltok_impl.c upstream then?
#ifdef __clang__
#pragma clang diagnostic ignored "-Wunreachable-code-fallthrough"
#endif hartwork commented on Jul 13, 2026 ContributorAuthor More actions @cdce8p I have no interest in adding things like that to the Expat code base. neek78 commented on Jul 13, 2026
@cdce8p I have no interest in adding things like that to the Expat code base.
i tend to agree. Libexpat has its own buildsystem(s), which set appropriate flags for the code; Cpython takes the code, but builds it itself. I would suggest making the change in Cpython's build system for building expat somewhere.
Out of interest, are these warnings showing up in CI ? cdce8p commented on Jul 13, 2026
I have no interest in adding things like that to the Expat code base.
In that case another option might be to add -Wno-unreachable-code-fallthrough here:
|
Modules/expat/xmltok.o: $(srcdir)/Modules/expat/xmltok.c $(LIBEXPAT_HEADERS) $(PYTHON_HEADERS) |
|
$(CC) -c $(LIBEXPAT_CFLAGS) -o $@ $(srcdir)/Modules/expat/xmltok.c |
@StanFromIreland Would that be acceptable? StanFromIreland commented on Jul 13, 2026 I don't think we should be ignoring warnings, we also shouldn't be fixing them, they should be resolved upstream instead. Previously, there were several warnings which this update allowed us to remove from our ignore list. hartwork commented on Jul 13, 2026 ContributorAuthor More actions I would like to note that Expat CI is using -Wall -Wextra -pedantic with -Werror and that -Wunreachable-code-fallthrough is beyond that. The goal of libexpat is to fix bugs, not to address warnings beyond -Wextra that do not expose actual bugs. If there is a bug to fix related to this warning, an in-depth analysis is welcome upstream. cdce8p commented on Jul 13, 2026
I would like to note that Expat CI is using -Wall -Wextra -pedantic with -Werror and that -Wunreachable-code-fallthrough is beyond that.
To be fair, AFAIK CPython only enables -Wunreachable-code explicitly. While I do share the desire to get these kind of changes upstream, I can also understand the position not to include it. Anyway, I opened #153671 in case silencing it during the build is ok. There at least seems to be some precedent to doing that for other warning types.
|
Modules/_hacl/Hacl_Streaming_HMAC.o: $(srcdir)/Modules/_hacl/Hacl_Streaming_HMAC.c $(LIBHACL_HMAC_HEADERS) |
|
$(CC) -Wno-unused-variable -c $(LIBHACL_CFLAGS) -o $@ $(srcdir)/Modules/_hacl/Hacl_Streaming_HMAC.c |
MetadataMetadataStatusShow more project fields
DevelopmentNo branches or pull requestsIssue actions
|