We ship .pyc files in python related packages. Some (should be most?) python projects create set/map literals in their source and we compile them into .pyc files. Python randomly order the set/map literals and makes the .pyc files not reproducible. Archlinux and Fedora suggest the use of PYTHONHASHSEED=0. Debian is not affected since they simply don't ship .pyc with them. See: https://archlinux.org/todo/unreproducible-python-bytecode/ https://src.fedoraproject.org/rpms/python-rpm-macros/pull-request/73
Doesn't this have some security implications? https://lwn.net/Articles/474912/ https://lwn.net/Articles/916204/ https://docs.python.org/3/using/cmdline.html#cmdoption-R http://ocert.org/advisories/ocert-2011-003.html
Unclear why https://github.com/python/cpython/pull/25411 was closed.
(In reply to Sam James from comment #1) > Doesn't this have some security implications? I suppose it's fine if we only set it in the Python eclasses, just not as a default in Python itself (i.e. we want the runtime randomisation, but not when producing .pyc).
(In reply to Sam James from comment #3) > (In reply to Sam James from comment #1) > > Doesn't this have some security implications? > > I suppose it's fine if we only set it in the Python eclasses, just not as a > default in Python itself (i.e. we want the runtime randomisation, but not > when producing .pyc). I tried with PYTHONHASHSEED=0 before run catalyst and result seems reproducible. But I don't know if it makes runtime hashing randomization disabled. A small sample seems not working even on a non-hacked build.
I would suggest that people who want reproducible builds just add PYTHONHASHSEED to make.conf. I don't see any reason to do it for everybody in the python eclasses.
