Thanks @benjaminp for the PR 🌮🎉.. I'm working now to backport this PR to: 3.6, 3.7, 3.8, 3.9.
🐍🍒⛏🤖

Sorry, @benjaminp, I could not cleanly backport this to 3.7 due to a conflict.
Please backport using cherry_picker on command line.
cherry_picker 916610ef90a0d0761f08747f7b0905541f0977c7 3.7

Sorry @benjaminp, I had trouble checking out the 3.6 backport branch.
Please backport using cherry_picker on command line.
cherry_picker 916610ef90a0d0761f08747f7b0905541f0977c7 3.6

Isn't the commit message here rather misleading? These weren't snprintf calls, which is exactly what allowed them to overflow. If this PR did what it claims to do, this would only be a bug fix for truncated precision when printing some values, not a security patch.

One can clearly see in the code that sprintf is being used, not snprintf.

Isn't the commit message here rather misleading? These weren't snprintf calls, which is exactly what allowed them to overflow. If this PR did what it claims to do, this would only be a bug fix for truncated precision when printing some values, not a security patch.

One can clearly see in the code that sprintf is being used, not snprintf.

It is. But I guess this is to be interpreted as "even better than just fixing it with the second best solution, which would be snprintf"

It is. But I guess this is to be interpreted as "even better than just fixing it with the second best solution, which would be snprintf"

That would be the wrong interpretation. To replace means to take the place of, and snprintf has no place in the affected changes.