-
-
Notifications
You must be signed in to change notification settings - Fork 1.9k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
pipenv injects secrets into Pipfile and lock file #3751
Comments
NOTE: one technique I had tested for keeping the high-level dependencies for a project in sync between the setup.py and the Pipfile was to put the definitions for the dependencies in the setup.py and do an editable install using pipenv, something like |
NOTE: I tried to manually work around this problem by editing the Pipfile by tring to force it to use the PIP_INDEX_URL environment variable using the env var expansion logic as follows:
However, after making this change and then running
|
Building upon my earlier comments, perhaps one easy solution for this problem could be to simply respect the use of the enviroment variable expansion in this case, and to preserve the Pipfile contents even when the PIP_INDEX_URL env var is found. To put this another way, if I rename the PIP_INDEX_URL env var to PIP_INDEX_URL2, update the Pipfile to reflect the change, and re-run my test command, I get the expected behavior. Here is a sample Pipfile to illustrate what I mean:
With this Pipfile, I can run NOTE: This is not a scalable solution for general use, however. Our team manages dozens of Python libraries and applications, not all of which would be using pipenv. For those that do not we would still need the PIP_INDEX_URL env var defined so the traditional package tools continue to work. Further, it would not be practical or safe for us to continually define and undefine this env var depending on the project we are working on because accidentally forgetting to undefine the variable could have the adverse effect of having our private credentials being injected into the config files and risk being committed to version control afterwards. This would be too risky and fragile to be considered a viable workaround. |
Yeah, you’re hitting an implementation detail imposed by how pip’s set up. The only solution is to choose another environment variable other than |
@AlJohri I'm not sure I quite understand. The Again, if I am mistaken with any of this just let me know. |
@uranusjr I'm not sure I understand your suggestion. In order to make Further, if we want to be able to build projects which use So, again, unless I'm misunderstanding something, I don't see how "avoiding variables with PIP_ in their names" achieves anything. Naming the environment variable anything else will effectively break |
Sorry, I elided some information in my previous post. Pipenv uses pip internally, and in order to implement There are multiple solutions to this problem, all on the same premise that you must avoid that environment variable to avoid stepping Pipenv’s toes. One is suggested above by @AlJohri—set up pip with pip.conf instead of environment variables. This is the best approach if you have non-Pipenv projects that also rely on the same system-wide index configuration. If you don’t, just pick a different environment variable name, and your |
Instead of putting the whole url for your internal mirror using
Edit: Above code is in the format from a Below is how your should setup your
|
@darrenmeehan You are correct that your suggestion does work around the problem I've described here. However it introduces a second problem: the index URL now needs to be duplicated both in the pipfile and in the global environment. In order for certain native / shell tools to work we need to have the PIP_INDEX_URL env var defined globally. This would result in the URL being duplicated both in the environment AND in the pipfile. This is less than ideal (ie: what if you want to redirect your repo elsewhere depending on your geo / network connection? You'd need to remember to update both.) |
@uranusjr Thanks for the suggestion. There is at least one case we've hit where the Also, your proposal still results in multiple sources of truth for the URL and credentials. You need to have the info duplicated in both the pip.conf and the pipenv file, which is less than ideal for the same reasons I mentioned earlier. If we could have it so the single source of truth for the connection parameters could be loaded from the environment variable that would be preferable. |
I believe this is resolvable now -- but let me know if its still an issue on |
we want to let you know that we reproduced with recents version (2023.9.8). In an empty directory, set |
@deronnax any chance you could post an example? Would also be wonderful to add to docs in the future |
Nop, we moved away from Pipenv months ago, sorry (for PDM). |
Hello, For info: we use |
@Alexander-Serov if I recall correctly, with the current behavior the secrets needs to be specified in env vars referenced by Opening this back up for now though in case there is a better solution. |
Thanks, @matteius, I will try out the env variables. And thanks for reopening: after all, the unconditional injection may be dangerous for non-advanced users who will then commit the token. |
I can confirm that installation of a private package with an environment var works:
However, the un-masked variable is written both to stdout and Pipfile/Pipfile.lock. Subsequently I was able to simply replace the un-masked variable with the env var as described in the docs. I.e. in Pipfile/Pipfile.lock:
I'm not sure if this process can be streamlined, as devs could easily forget to manually edit the files before committing and printing the un-masked token to stdout isn't desirable. But for now, this will be how I'm handling the situation. Thanks pipenv team! |
I added a bunch of unit tests around the env vars being maintained in lock file in recent |
Issue description
When running pipenv in an environment which has a PIP_INDEX_URL environment variable defined, and that env var contains credentials to use when authenticating to the package index server, those credentials are injected as plain-text into the Pipfile and Pipefile.lock files.
Expected result
pipenv should not inject index URLs containing credentials verbatim into the config file.
Actual result
pipenv does inject index URLs containing credentials into the config file.
Steps to replicate
We work behind a firewall with a mirror of the global PyPI repository in our lab. This mirror requires authentication to access. To make this work properly / easily with
pip
we generally expect users to define a custom PIP_INDEX_URL containing the users' credentials along with the URL for the mirror.Further, when using pipenv to create a new environment or install a package (ie:
pipenv install requests
), we end up getting a Pipfile that looks something like this:I debated whether this should be reported as a "bug" or perhaps just a feature request to have this behavior changed, however given the severity of the impact of this default behavior I thought it was better suited as a bug. The tools should never inject secrets into files that may be commited to version control and this behavior could be very easily overlooked by users of the tool, which makes me very hesitant to roll out this tool for widespread use on my team.
$ pipenv --support
Pipenv version:
'2018.11.26'
Pipenv location:
'/usr/local/lib/python3.7/site-packages/pipenv'
Python location:
'/usr/local/opt/python/bin/python3.7'
Python installations found:
3.7.2
:/usr/local/bin/python3
3.7.2
:/usr/local/bin/python3.7m
3.6.1
:/usr/local/bin/pypy3
3.5.2
:/usr/local/bin/python3.5m
3.5.2
:/usr/local/bin/python3.5
2.7.16
:/usr/local/bin/python
2.7.16
:/usr/local/bin/pythonw
2.7.13
:/usr/local/bin/pypy
2.7.10
:/usr/bin/python
2.7.10
:/usr/bin/pythonw
2.7.10
:/usr/bin/python2.7
PEP 508 Information:
System environment variables:
JENKINS_KEY
TERM_PROGRAM
TERM
SHELL
TMPDIR
Apple_PubSub_Socket_Render
VAULT_ADDR
TERM_PROGRAM_VERSION
PIP_INDEX_URL
OLDPWD
TERM_SESSION_ID
SDKMAN_PLATFORM
OBJC_DISABLE_INITIALIZE_FORK_SAFETY
USER
SDKMAN_CANDIDATES_API
PIP_INDEX_URL2
GITLAB_API_TOKEN
SSH_AUTH_SOCK
ART_KEY
LSCOLORS
PATH
PWD
JAVA_HOME
LANG
SDKMAN_VERSION
XPC_FLAGS
PS1
XPC_SERVICE_NAME
HOME
SHLVL
LOGNAME
SDKMAN_DIR
GROOVY_HOME
SDKMAN_CANDIDATES_DIR
JENKINS_SANDBOX_KEY
DISPLAY
_
__CF_USER_TEXT_ENCODING
PIP_DISABLE_PIP_VERSION_CHECK
PYTHONDONTWRITEBYTECODE
PIP_SHIMS_BASE_MODULE
PIP_PYTHON_PATH
PYTHONFINDER_IGNORE_UNSUPPORTED
Pipenv–specific environment variables:
Debug–specific environment variables:
PATH
:/usr/X11R6/bin:/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin:/usr/local/go/bin:/opt/X11/bin:~/Documents/node_modules/.bin
SHELL
:/bin/bash
LANG
:en_CA.UTF-8
PWD
:*******
Contents of
Pipfile
('******/Pipfile'):Contents of
Pipfile.lock
('*****/Pipfile.lock'):The text was updated successfully, but these errors were encountered: