Unsafe Python Environment

[XVicarious]

Jedi by default seems to require the python executable to owned by the root user for safety reasons. It appears without setting the safe parameter in create_environment to False, you will be unable to use a virtual environment for your projects.

The relevant line is

SourcetrailPythonIndexer/indexer.py

Line 28 in 8b1dc11

environment = jedi.create_environment(environmentPath)

CoatiSoftware/Sourcetrail/issues/697

[mlangkabel]

Thank you for looking into it! So I think this is the relevant comment in the Jedi code:

    # The interpreter needs to be owned by root. This means that it wasn't
    # written by a user and therefore attacking Jedi is not as simple.
    # The attack could look like the following:
    # 1. A user clones a repository.
    # 2. The repository has an innocent looking folder called foobar. jedi
    #    searches for the folder and executes foobar/bin/python --version if
    #    there's also a foobar/bin/activate.
    # 3. The bin/python is obviously not a python script but a bash script or
    #    whatever the attacker wants.

[XVicarious]

That is true, however its common practice to use a virtual environment with something like pyenv for individual projects to keep everything just right, and they're owned by the user.

Perhaps you can use get_default_environment . For reference: jedi-vim

[mlangkabel]

So if I understand it correctly, the Jedi comment is talking about a user that check out a repository that already contains a virtual python environment (which may be a safety risk)?

[XVicarious]

That seems to be the reasoning to me. I can confirm it works with my virtual environment when I'm using the jedi-vim plugin.

[mlangkabel]

Ok, then I would suggest that we use only safe environments if the user doesn't specify a specific one, but if the user explicitly provide one (via the Sourcetrail project settings), also "unsafe" environments shall be allowed.

[XVicarious]

Sounds like a fair compromise to me.

[mlangkabel]

fixed with merge of pull request #60

[robinst]

This doesn't seem to be released yet. Is there a nightly build available to try out?

[mlangkabel]

That's right. It has been fixed in the code. Now we need to create a new SourcetrailPythonIndexer release. You could download and extract that release and replace the data/python folder of your Sourcetrail package. Getting it into a new Sourcetrail Release will take longer.

I will schedule the SourcetrailPythonIndexer release now, and let you know once it is available.