You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This means that when isolated mode is used to turn off environment variable access, PYTHONHASHSEED may still be read while configuring hash randomisation.
This issue has been fixed in Python 3.8 with my work on refactoring Py_Main(). -E and -I command line options are now parsed, before reading PYTHONHASHSEED, and -I imply -E as expected. Extract of the code:
if (config->isolated>0) {
config->user_site_directory=0;
}
if (config->use_environment) {
err=config_read_env_vars(config);
if (_Py_INIT_FAILED(err)) {
returnerr;
}
}
where config_read_env_vars() indirectly reads PYTHONHASHSEED.
I'm not sure if the issue is fixed in Python 3.7 or not. The code in Python 3.7 was in a bad state. It's getting better with Python 3.8 :-)
Note: the overall refactoring work is related to PEP-432 and PEP-587.
Activity
ncoghlan commentedon Jan 15, 2016
While working on the draft PEP-432 implementation, I noticed that -I isn't special cased for early processing the same way that -E is: https://hg.python.org/cpython/file/tip/Modules/main.c#l265
This means that when isolated mode is used to turn off environment variable access, PYTHONHASHSEED may still be read while configuring hash randomisation.
vstinner commentedon May 15, 2019
This issue has been fixed in Python 3.8 with my work on refactoring Py_Main(). -E and -I command line options are now parsed, before reading PYTHONHASHSEED, and -I imply -E as expected. Extract of the code:
where config_read_env_vars() indirectly reads PYTHONHASHSEED.
I'm not sure if the issue is fixed in Python 3.7 or not. The code in Python 3.7 was in a bad state. It's getting better with Python 3.8 :-)
Note: the overall refactoring work is related to PEP-432 and PEP-587.
tiran commentedon May 15, 2019
Is there a way to fix the issue in 3.7 and earlier? We might consider it a security issue.
vstinner commentedon May 20, 2019
Hum, Python 3.7 is fixed as well. At least, in the 3.7 dev branch.
Fixed seed:
vstinner@apu$ PYTHONHASHSEED=42 ./python -c 'print(set("abcdefgh"))'
{'g', 'e', 'a', 'b', 'c', 'f', 'h', 'd'}
vstinner@apu$ PYTHONHASHSEED=42 ./python -c 'print(set("abcdefgh"))'
{'g', 'e', 'a', 'b', 'c', 'f', 'h', 'd'}
vstinner@apu$ PYTHONHASHSEED=42 ./python -c 'print(set("abcdefgh"))'
{'g', 'e', 'a', 'b', 'c', 'f', 'h', 'd'}
vstinner@apu$ PYTHONHASHSEED=42 ./python -c 'print(set("abcdefgh"))'
{'g', 'e', 'a', 'b', 'c', 'f', 'h', 'd'}
Random seed:
vstinner@apu$ PYTHONHASHSEED=42 ./python -I -c 'print(set("abcdefgh"))'
{'b', 'e', 'd', 'f', 'g', 'c', 'a', 'h'}
vstinner@apu$ PYTHONHASHSEED=42 ./python -I -c 'print(set("abcdefgh"))'
{'d', 'g', 'e', 'b', 'h', 'f', 'a', 'c'}
vstinner@apu$ PYTHONHASHSEED=42 ./python -I -c 'print(set("abcdefgh"))'
{'e', 'b', 'g', 'c', 'a', 'h', 'f', 'd'}
vstinner@apu$ PYTHONHASHSEED=42 ./python -I -c 'print(set("abcdefgh"))'
{'c', 'd', 'a', 'g', 'f', 'e', 'h', 'b'}
--
Python 3.6 has the bug:
vstinner@apu$ PYTHONHASHSEED=42 python3.6 -c 'print(set("abcdefgh"))'
{'g', 'e', 'a', 'b', 'c', 'f', 'h', 'd'}
vstinner@apu$ PYTHONHASHSEED=42 python3.6 -c 'print(set("abcdefgh"))'
{'g', 'e', 'a', 'b', 'c', 'f', 'h', 'd'}
vstinner@apu$ PYTHONHASHSEED=42 python3.6 -c 'print(set("abcdefgh"))'
{'g', 'e', 'a', 'b', 'c', 'f', 'h', 'd'}
vstinner@apu$ PYTHONHASHSEED=42 python3.6 -c 'print(set("abcdefgh"))'
{'g', 'e', 'a', 'b', 'c', 'f', 'h', 'd'}
vstinner@apu$ PYTHONHASHSEED=42 python3.6 -I -c 'print(set("abcdefgh"))'
{'g', 'e', 'a', 'b', 'c', 'f', 'h', 'd'}
vstinner@apu$ PYTHONHASHSEED=42 python3.6 -I -c 'print(set("abcdefgh"))'
{'g', 'e', 'a', 'b', 'c', 'f', 'h', 'd'}
vstinner@apu$ PYTHONHASHSEED=42 python3.6 -I -c 'print(set("abcdefgh"))'
{'g', 'e', 'a', 'b', 'c', 'f', 'h', 'd'}
vstinner@apu$ PYTHONHASHSEED=42 python3.6 -I -c 'print(set("abcdefgh"))'
{'g', 'e', 'a', 'b', 'c', 'f', 'h', 'd'}