All commit authors signed the Contributor License Agreement.

Most changes to Pythonrequire a NEWS entry. Add one using theblurb_it web app or theblurb command-line tool.

If this change has little impact on Python users, wait for a maintainer to apply theskip news label instead.

I suspect this PR has been generated by an LLM, or at least the description had. Can you confirm this? Because it's not a security issue. In addition, please read our policy on what when using LLM is acceptable:https://devguide.python.org/getting-started/generative-ai/ (if English isn't your first language, it's fine, but please indicate whether an LLM has been used and how).

I suspect this PR has been generated by an LLM, or at least the description had. Can you confirm this? Because it's not a security issue. In addition, please read our policy on what when using LLM is acceptable:https://devguide.python.org/getting-started/generative-ai/ (if English isn't your first language, it's fine, but please indicate whether an LLM has been used and how).

@picnixz I'm sorry, I always considered heap-buffer-overflow an exploitable issue. But I changed the language to "bug", perhaps more aligned with the reported issue. Is that ok?

Bugs like that only become security issues when they are exploitable and we need to assess how feasible for an adversary it is to exploit it. In our case, the attack surface is very small and relies on invoking "semi-public" functions (and then it should be exploitable! usually there is just a hard crash, which could be considered a DoS in some sense if it's serving a web app with auto-reload for instance).

Anyway, now, I'd like you to confirm whether this has been generated by a LLM or not (and if so, which part). I'm sorry to be doubtful but because of the emergence of LLM, we have many new contributors that simply use LLM to generate their PRs and that is unacceptable.

Bugs like that only become security issues when they are exploitable and we need to assess how feasible for an adversary it is to exploit it. In our case, the attack surface is very small and relies on invoking "semi-public" functions (and then it should be exploitable! usually there is just a hard crash, which could be considered a DoS in some sense if it's serving a web app with auto-reload for instance).

Anyway, now, I'd like you to confirm whether this has been generated by a LLM or not (and if so, which part). I'm sorry to be doubtful but because of the emergence of LLM, we have many new contributors that simply use LLM to generate their PRs and that is unacceptable.

@picnixz PR description proofread with ChatGTP, but if that represents a violation I'm ok with closing the PR

If it's only the description, it's fine. But in the future, you don't need to have an LLM generate the description. We don't really care which files were modified for instance (though it's good to know if breaking changes were introduced) or whether the tests were added (we expect them to be added!) Affected versions are already mentioned on the issue as well.

@picnixz Thec_make_encoder is only called once (here:https://github.com/python/cpython/blob/main/Lib/json/encoder.py#L254) and is semi-private. We could make it private and change the invocation from:

            _iterencode = c_make_encoder(                markers, self.default, _encoder, indent,                self.key_separator, self.item_separator, self.sort_keys,                self.skipkeys, self.allow_nan)

to

            _iterencode = c_make_encoder(                markers, self.default, _encoder, str(indent),                self.key_separator, self.item_separator, self.sort_keys,                self.skipkeys, self.allow_nan)

@caverac I agree with you that performance is not really impacted (for any of the solutions proposed so far). But if you do want to test it: usehttps://github.com/psf/pyperf or the timeit module with much smaller json files.

@picnixz Thec_make_encoder is only called once (here:https://github.com/python/cpython/blob/main/Lib/json/encoder.py#L254) and is semi-private. We could make it private and change the invocation from:

            _iterencode = c_make_encoder(                markers, self.default, _encoder, indent,                self.key_separator, self.item_separator, self.sort_keys,                self.skipkeys, self.allow_nan)

to

            _iterencode = c_make_encoder(                markers, self.default, _encoder, str(indent),                self.key_separator, self.item_separator, self.sort_keys,                self.skipkeys, self.allow_nan)

@caverac I agree with you that performance is not really impacted (for any of the solutions proposed so far). But if you do want to test it: usehttps://github.com/psf/pyperf or the timeit module with much smaller json files.

@eendebakpt Making a bit of an update to your suggestion will definitely work

_iterencode=c_make_encoder(markers,self.default,_encoder,NoneifindentisNoneelsestr(indent),# <== this lineself.key_separator,self.item_separator,self.sort_keys,self.skipkeys,self.allow_nan)

And it both: drastically reduces the footprint of my changes and removes any concerns about performance. But your other example still fails

importjsonindent='  'encoder=json.encoder.c_make_encoder(None,default=lambdaobj:obj,encoder=lambdaobj:obj,indent=indent,key_separator=":",item_separator=", ",skipkeys=False,allow_nan=False,sort_keys=False,                   )print('start')encoder([None],1)print('end')

even if we change the import. I'm looking for guidance here, which version of this do we want "This is internal, misuse is your own fault" v. "Even if you misuse it, we won't crash"?

Perhaps adding this check

if (indent_level!=0) {PyErr_SetString(PyExc_ValueError,"_current_indent_level must be 0 when indent is set");PyUnicodeWriter_Discard(writer);returnNULL;        }

is a good compromise?

#143618 is a simpler solution.