get_resource_filename issue

Issue #375 resolved
Jason R. Coombs
created an issue

This placeholder will be replaced when the details behind a security issue are made public.

Comments (11)

  1. Jason R. Coombs reporter

    Thanks for the report. I've corrected the issue and released the fix in 0.6.47. It would be nice if this regression were covered by a unit test. I'll file a ticket to that effect for setuptools.

  2. David Kindred

    My company has a build machine that has been regularly building eggs for years without a problem and yesterday we noticed that we started getting an exception mentioned above. We thought we had locked the version of setuptools we are using to 0.6.c11, but evidently it has been mysteriously going out and upgrading to the latest version of setuptools even though we used --no-site-packages and specify the repository to look at. I read that this problem was fixed with setuptools 0.7.6, but I'm still seeing the problem. So, I have two questions: 1) Do you know how I can prevent setuptools from getting updated to the latest version, and 2) Is the fix that mentioned here for distribute actually in the 0.7.6 setuptools?

  3. Jason R. Coombs reporter

    I've patched the code again and re-released as Distribute 0.6.48 and Setuptools 0.7.7 and 0.8b5. Sorry for all the noise. As a result, I raised the priority of setuptools #30 and added a test to verify the fix. Please report back if this doesn't address the issue.

  4. Jason R. Coombs reporter

    @David Kindred Regarding (1), it depends on how setuptools 0.7 is being installed. In general, you have to invoke 'easy_install -U' or 'pip install --upgrade' to cause setuptools to be upgraded. Or, if you don't have setuptools at all, invoking will always get the latest, because it only specifies a lower bound. You'll have to investigate in your particular environment to determine when the upgrade is happening and alter that command to avoid the upgrade. Except when stupid bugs like this one are present, however, 0.7 is generally recommended over 0.6.

    Sorry for any inconvenience. I hope soon to provide a full report explaining the underlying security problem and why this effort was back-ported to Distribute.

  5. Arfrever Frehtes Taifersar Arahesis
    • changed status to open

    Unfortunately there is another exception, which occurs when extraction directory does not exist:

      File "/usr/lib64/python2.7/site-packages/", line 914, in resource_filename
        self, resource_name
      File "/usr/lib64/python2.7/site-packages/", line 1602, in get_resource_filename
        return self._extract_resource(manager, zip_path)
      File "/usr/lib64/python2.7/site-packages/", line 1657, in _extract_resource
        manager.extraction_error()  # report a user-friendly error
      File "/usr/lib64/python2.7/site-packages/", line 960, in extraction_error
        raise err
    pkg_resources.ExtractionError: Can't extract file(s) to egg cache
    The following error occurred while trying to extract file(s) to the Python egg
      [Errno 2] No such file or directory: '/home/Arfrever/.python-eggs'
    The Python egg cache directory is currently set to:
    Perhaps your account does not have write access to this directory?  You can
    change the cache directory by setting the PYTHON_EGG_CACHE environment
    variable to point to an accessible directory.

    The original exception (OSError: [Errno 2] No such file or directory) is caused by the following line in _warn_unsafe_extraction_path():

    mode = os.stat(path).st_mode

    Maybe something similar to the following loop should be used (before above line):

    if ( == 'nt' and os.path.exists(os.path.split(path)[0]) or != 'nt' and path.startswith(os.path.sep)):
        while not os.path.exists(path):
            path = os.path.dirname(path)
        return   # Fully invalid path, so there will be an exception anyway
  6. Log in to comment