On a routine upgrade of everything, dev-python/cryptography-0.9.3 failed to install To issues are apparent: 1. A strange attempt to install a directory in my personal python library, which fails 2. Inability to import enum Reproducible: Always Steps to Reproduce: 1.emerge -av =dev-python/cryptography-0.9.3 2. 3. Actual Results: 686-pc-linux-gnu-gcc -O2 -march=native -pipe -fPIC -I/usr/include/python2.7 -c src/cryptography/hazmat/bindings/__pycache__/_Cryptography_cffi_26cb75b8x62b488b1.c -o /var/tmp/portage/dev-python/cryptography-0.9.3/work/cryptography-0.9.3-python2_7/temp.linux-i686-2.7/src/cryptography/hazmat/bindings/__pycache__/_Cryptography_cffi_26cb75b8x62b488b1.o i686-pc-linux-gnu-gcc -shared -Wl,-O1 -Wl,--as-needed -O2 -march=native -pipe /var/tmp/portage/dev-python/cryptography-0.9.3/work/cryptography-0.9.3-python2_7/temp.linux-i686-2.7/src/cryptography/hazmat/bindings/__pycache__/_Cryptography_cffi_26cb75b8x62b488b1.o -L/usr/lib -lpython2.7 -o /var/tmp/portage/dev-python/cryptography-0.9.3/work/cryptography-0.9.3-python2_7/lib/cryptography/_Cryptography_cffi_26cb75b8x62b488b1.so >>> Source compiled. >>> Test phase [not enabled]: dev-python/cryptography-0.9.3 >>> Install cryptography-0.9.3 into /var/tmp/portage/dev-python/cryptography-0.9.3/image/ category dev-python * python3_3: running distutils-r1_run_phase distutils-r1_python_install /usr/bin/python3.3 setup.py install --root=/var/tmp/portage/dev-python/cryptography-0.9.3/image//_python3.3 running install * ACCESS DENIED: mkdir: /home/paul/lib/python/__pycache__ Traceback (most recent call last): File "setup.py", line 342, in <module> **keywords_with_side_effects(sys.argv) File "/usr/lib/python3.3/distutils/core.py", line 148, in setup dist.run_commands() File "/usr/lib/python3.3/distutils/dist.py", line 930, in run_commands self.run_command(cmd) File "/usr/lib/python3.3/distutils/dist.py", line 948, in run_command cmd_obj.ensure_finalized() File "/usr/lib/python3.3/distutils/cmd.py", line 107, in ensure_finalized self.finalize_options() File "setup.py", line 120, in finalize_options self.distribution.ext_modules = get_ext_modules() File "setup.py", line 85, in get_ext_modules from cryptography.hazmat.primitives import constant_time, padding File "src/cryptography/hazmat/primitives/padding.py", line 14, in <module> from cryptography.exceptions import AlreadyFinalized File "src/cryptography/exceptions.py", line 7, in <module> from enum import Enum ImportError: cannot import name Enum * ERROR: dev-python/cryptography-0.9.3::gentoo failed (install phase): * (no error message) * * Call stack: * ebuild.sh, line 93: Called src_install * environment, line 3541: Called distutils-r1_src_install * environment, line 941: Called _distutils-r1_run_foreach_impl 'distutils-r1_python_install' * environment, line 342: Called python_foreach_impl 'distutils-r1_run_phase' 'distutils-r1_python_install' * environment, line 3105: Called multibuild_foreach_variant '_python_multibuild_wrapper' 'distutils-r1_run_phase' 'distutils-r1_python_install' * environment, line 2229: Called _multibuild_run '_python_multibuild_wrapper' 'distutils-r1_run_phase' 'distutils-r1_python_install' * environment, line 2227: Called _python_multibuild_wrapper 'distutils-r1_run_phase' 'distutils-r1_python_install' * environment, line 603: Called distutils-r1_run_phase 'distutils-r1_python_install' * environment, line 910: Called distutils-r1_python_install * environment, line 832: Called esetup.py 'install' '--root=/var/tmp/portage/dev-python/cryptography-0.9.3/image//_python3.3' * environment, line 1398: Called die * The specific snippet of code: * "${@}" || die * * If you need support, post the output of `emerge --info '=dev-python/cryptography-0.9.3::gentoo'`, * the complete build log and the output of `emerge -pqv '=dev-python/cryptography-0.9.3::gentoo'`. * The complete build log is located at '/var/tmp/portage/dev-python/cryptography-0.9.3/temp/build.log'. * The ebuild environment file is located at '/var/tmp/portage/dev-python/cryptography-0.9.3/temp/environment'. * Working directory: '/var/tmp/portage/dev-python/cryptography-0.9.3/work/cryptography-0.9.3' * S: '/var/tmp/portage/dev-python/cryptography-0.9.3/work/cryptography-0.9.3' * --------------------------- ACCESS VIOLATION SUMMARY --------------------------- * LOG FILE: "/var/log/sandbox/sandbox-2138.log" * VERSION 1.0 FORMAT: F - Function called FORMAT: S - Access Status FORMAT: P - Path as passed to function FORMAT: A - Absolute Path (not canonical) FORMAT: R - Canonical Path FORMAT: C - Command Line F: mkdir S: deny P: /home/paul/lib/python/__pycache__ A: /home/paul/lib/python/__pycache__ R: /home/paul/lib/python/__pycache__ C: /usr/bin/python3.3 setup.py install --root=/var/tmp/portage/dev-python/cryptography-0.9.3/image//_python3.3 * -------------------------------------------------------------------------------- >>> Failed to emerge dev-python/cryptography-0.9.3, Log file: >>> '/var/tmp/portage/dev-python/cryptography-0.9.3/temp/build.log' Expected Results: Installs normally
Created attachment 411044 [details] Portage log file
Created attachment 411046 [details] emerge --info
which version of dev-python/enum34 with which USE do you have installed?
1.0
I have just noticed that I have an 'enum.py' at /home/paul/lib/python, and the above directory is in my PYTHONPATH. But I'm thinking an install of this ebuild (and Gentoo python installs in general) should *not* be picking up personal libraries--there could be also sorts of crazy stuff on the path...
Why is a user's dir in your global PYTHONPATH?
I would have said that it is the other way round: why shouldn't a user's library be included on the PYTHONPATH? What seems to be happening is that the PYTHONPATH set in my user account .bashrc file is being carried across to the root user environment when I 'su'. But all this would seem to me to be normal practice. Shouldn't Gentoo be ignoring any custom paths in PYTHONPATH, and just be using the default system information supplied in sys,path? Otherwise Gentoo will be very brittle. Of course, I can switch to root with 'su -' and leave the user's original environment behind...but I don't believe this is the norm (otherwise it should be the default), and I don't recall any Gentoo advice that one has to do 'su -' when installing ebuilds.
There are all sorts of ways you can break portage by setting random environment variables. Just search for "portage environment" in bugzilla for some examples. That said, I suppose we could unset PYTHONPATH in some early phase in distutils-r1.eclass. Can anyone think of a reason NOT to do that?
I can confirm that installation worked OK after su-ing with 'su -'. "There are all sorts of ways you can break portage by setting random environment variables. Just search for "portage environment" in bugzilla for some examples." To me this suggests that the Gentoo approach here could be more robust. There could be absolutely anything in the environment, but really Gentoo should install OK regardless. Clearly installation works with PYTHONPATH unset, so paying any attention to this variable is redundant, and is going to lead to random installation issues like the one I just experienced. It also looks like a bit of a security issue to me. I'm no expert, but if the admin user who does 'su' has got something malicious in his PYTHONPATH which is going to lead to a file being executed by Gentoo then this could be a problem.
(In reply to Paul from comment #9) > To me this suggests that the Gentoo approach here could be more robust. > There could be absolutely anything in the environment, but really Gentoo > should install OK regardless. It's a 2-sided issue: sometimes it is very handy to be able to set an environment variable to control some behavior. Sometimes it breaks things. If you have some bright idea, please file a feature request bug or discuss it on the gentoo-dev mailing list. > It also looks like a bit of a security issue to me. I'm no expert, but if > the admin user who does 'su' has got something malicious in his PYTHONPATH > which is going to lead to a file being executed by Gentoo then this could be > a problem. That would be an issue regardless of portage; don't run su from an account which may be compromised.
 commit c3c2f1823de4a8a9c479c2c874a846c4de30d3d9 Author: Justin Lecher <jlec@gentoo.org> Date: Thu Nov 12 10:26:21 2015 +0100 dev-python/cryptography: Drop vulnerable versions Gentoo-Bug: https://bugs.gentoo.org/show_bug.cgi?id=561696 obsoletes: Gentoo-Bug: https://bugs.gentoo.org/show_bug.cgi?id=561604 Gentoo-Bug: https://bugs.gentoo.org/show_bug.cgi?id=559648 Gentoo-Bug: https://bugs.gentoo.org/show_bug.cgi?id=521796 Package-Manager: portage-2.2.23 Signed-off-by: Justin Lecher <jlec@gentoo.org> https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=c3c2f1823de4a8a9c479c2c874a846c4de30d3d9
