Hi @zooba
I was exploring this and in the mean time i got this error
▶ ./python -m trace --trace Lib/calendar.py
File "Lib/calendar.py", line 155, in monthrange
ndays = mdays[month] + (month == FEBRUARY and isleap(year))
^^^^^^^^
NameError: name 'FEBRUARY' is not defined
FEBRUARY is a global attribute for this module which is made using the global_enum decorator over an enum but trace is throwing an exception that FEBRUARY is not defined
several std libs are throwing one or the other error
Btw, is the issue just about changing the open to io.open_code?
Because we made a promise that files being opened for execution would go through open_code, and execution is a sensitive path. Plus it's something that anyone building their own security releases would want to backport, so we can save them all the work.
The pdb change should be backported as well.
(I removed 3.7 because this was all added in 3.8.)
Activity
Agent-Hellboy commented on Apr 27, 2023
Hi @zooba
I was exploring this and in the mean time i got this error
▶ ./python -m trace --trace Lib/calendar.py
File "Lib/calendar.py", line 155, in monthrange ndays = mdays[month] + (month == FEBRUARY and isleap(year)) ^^^^^^^^ NameError: name 'FEBRUARY' is not definedFEBRUARY is a global attribute for this module which is made using the global_enum decorator over an enum but trace is throwing an exception that FEBRUARY is not defined
several std libs are throwing one or the other error
Btw, is the issue just about changing the open to io.open_code?
gaogaotiantian commented on Apr 27, 2023
Could you explain why this is a security issue? A similar PR was done for pdb a couple of days ago #103581.
zooba commented on Apr 27, 2023
Because we made a promise that files being opened for execution would go through open_code, and execution is a sensitive path. Plus it's something that anyone building their own security releases would want to backport, so we can save them all the work.
The pdb change should be backported as well.
(I removed 3.7 because this was all added in 3.8.)
zooba commented on Apr 27, 2023
I stand corrected - pdb was fine in 3.8-3.10, someone regressed it in 3.11, which has now been fixed.
gaogaotiantian commented on Apr 27, 2023
Thank you for the explanation! In that case, do you want me to submit a PR to fix profile and cProfile which also use raw open for executable code?
zooba commented on Apr 27, 2023
Sure, go ahead. They can all go in the same PR
zooba commented on Apr 27, 2023
Incidentally, I checked out the other open() calls in trace and they're all fine. It's just the one that I point out in the first message.
gaogaotiantian commented on Apr 27, 2023
I also did a quick scan for other similar usages, but did not find any Lib code that loads an executable file.
1 remaining item
pythongh-103935: Use `io.open_code()` when executing code in trace an…
pythongh-103935: Use `io.open_code()` when executing code in trace an…
pythongh-103935: Use `io.open_code()` when executing code in trace an…
gh-103935: Use `io.open_code()` when executing code in trace and prof…
gh-103935: Use `io.open_code()` when executing code in trace and prof…
[3.8] gh-103935: Use `io.open_code()` when executing code in trace an…
[3.9] gh-103935: Use `io.open_code()` when executing code in trace an…
Upgrade to 3.8.17 (#26)