Credentials are leaked in requirements.txt

[Grutschus]

Issue description

When I run pipenv requirements with an index-url specified in the pipfile according to this page in the docs, pipenv reveals the credentials in the requirements.txt.

Expected result

I'd expect the requirements.txt to contain a reference to the environment variable, just like in the Pipfile.lock.

Actual result

The credentials are clearly visible in the requirements.txt.

Steps to replicate

mkdir my_project
cd my_project

touch Pipfile
pipenv install

Add you private pypi repo to the pipfile.

pipenv requirements

---

Please run $ pipenv --support, and paste the results here. Don't put backticks (`) around it! The output already contains Markdown formatting.

$ pipenv --support

Pipenv version: '2022.6.7'

Pipenv location: '/anaconda/lib/python3.8/site-packages/pipenv'

Python location: '/anaconda/bin/python'

Python installations found:

• 3.8.10: /anaconda/bin/python3
• 3.8.10: /anaconda/bin/python
• 3.8.10: /anaconda/bin/python3.8
• 3.6.9: /usr/bin/python3.6
• 3.6.9: /usr/bin/python3.6m
• 3.6.9: /usr/bin/python3
• 2.7.17: /usr/bin/python2
• 2.7.17: /usr/bin/python2.7
• 2.7.17: /usr/bin/python

PEP 508 Information:

{'implementation_name': 'cpython',
 'implementation_version': '3.8.10',
 'os_name': 'posix',
 'platform_machine': 'x86_64',
 'platform_python_implementation': 'CPython',
 'platform_release': '5.4.0-1068-azure',
 'platform_system': 'Linux',
 'platform_version': '#71~18.04.1-Ubuntu SMP Thu Jan 20 08:21:40 UTC 2022',
 'python_full_version': '3.8.10',
 'python_version': '3.8',
 'sys_platform': 'linux'}

System environment variables:

• CONDA_SHLVL
• MSI_ENDPOINT
• LS_COLORS
• LD_LIBRARY_PATH
• CONDA_EXE
• JUPYTER_SERVER_ROOT
• LESSCLOSE
• LANG
• AZURE_EXTENSION_DIR
• MSI_SECRET_JOB
• OLDPWD
• INVOCATION_ID
• CI_RESOURCE_GROUP
• NODE_PATH
• OBO_ENDPOINT
• COLORTERM
• JUPYTER_SERVER_URL
• CONDA_PREFIX
• VSCODE_GIT_ASKPASS_EXTRA_ARGS
• CLASSPATH
• USER
• AML_CloudName
• CI_WORKSPACE
• MKL_THREADING_LAYER
• PWD
• LINES
• HOME
• CONDA_PYTHON_EXE
• BROWSER
• JOURNAL_STREAM
• VSCODE_GIT_ASKPASS_NODE
• TERM_PROGRAM
• TERM_PROGRAM_VERSION
• CUPIT_LIB_PATH
• XDG_DATA_DIRS
• DEFAULT_IDENTITY_CLIENT_ID
• APPSETTING_WEBSITE_SITE_NAME
• VSCODE_IPC_HOOK_CLI
• CUDA_ROOT
• LIBRARY_PATH
• CONDA_PROMPT_MODIFIER
• COLUMNS
• CI_NAME
• VSCODE_GIT_ASKPASS_MAIN
• SHELL
• TERM
• MSI_SECRET
• AZURE_ARTIFACTS_PAT
• PYXTERM_DIMENSIONS
• SHLVL
• CI_LOCAL_UBUNTU_USER
• VSCODE_GIT_IPC_HANDLE
• MANPATH
• LOGNAME
• MLFLOW_TRACKING_URI
• GIT_ASKPASS
• ENABLE_MLFLOW_AUTOLOG
• PATH
• CONDA_DEFAULT_ENV
• I_MPI_ROOT
• LESSOPEN
• _
• PIP_SHIMS_BASE_MODULE
• PIP_DISABLE_PIP_VERSION_CHECK
• PIP_PYTHON_PATH
• PYTHONDONTWRITEBYTECODE
• PYTHONFINDER_IGNORE_UNSUPPORTED

Pipenv–specific environment variables:

Debug–specific environment variables:

---

Contents of Pipfile:

[[source]]
url = "https://user:${AZURE_ARTIFACTS_PAT}@pkgs.dev.azure.com/my-project/pypi/simple/"
verify_ssl = true
name = "my-stream"

[packages]
my-package = "*"

[dev-packages]

[requires]
python_version = "3.8.10"

Contents of Pipfile.lock:

{
    "_meta": {
        "hash": {
            "sha256": "3349f2aaf4cd14ce1860f4c6971a3b3b4f0971f8ea30da5919c2542386512c28"
        },
        "pipfile-spec": 6,
        "requires": {
            "python_version": "3.8.10"
        },
        "sources": [
            {
                "name": "my-stream",
                "url": "https://user:${AZURE_ARTIFACTS_PAT}@pkgs.dev.azure.com/my-project/pypi/simple/",
                "verify_ssl": true
            }
        ]
    },
    "default": {
        "my-package": {
            "hashes": [
                "sha256:c49c1166e35955b2f817bca7f2f9a0854b5995a8f8173e1dc525024475f4756e",
                "sha256:e4345b3f508c33f582ab59e9f69707bc8f764c96ea5434e9adbfc344cd1aee80"
            ],
            "index": "my-package",
            "version": "==0.1.6"
        },
    "develop": {}
}

[matteius]

Hey @ImreC here is another refinement requested for the requirements command -- I defer to you if you can have a look at this when you find time? I think we are getting close to solving some of the last edge cases of the command preventing us from dropping the the lock -r version.

[ghost]

Hey hey,
just tried to fix the issue myself in #5139. Hope this helps :)

[oz123]

Thanks for your contribution. The issue is now fixed.