Forced pip update raises supply chain safety concerns (and is often useless)

Không có tệp mã nguồn, bài kiểm thử hoặc điểm vào nào được nêu. Hãy bắt đầu bằng việc lần theo đường dẫn tự động cập nhật pip của setup-python và cách đầu vào pip-version được xử lý; được xem là hoàn thành khi các bên gọi có thể chọn không tham gia, tránh cập nhật vô điều kiện lên phiên bản mới nhất và áp dụng an toàn cooldown được đề xuất.

Description:

As of v6.3.0, setup-python appears to unconditionally auto-update pip, without a dependency cooldown.
Even when a pip-version input is specified, setup-python seemingly updates pip to the latest version first, then installs the specified version.

This behavior raises supply chain safety concerns: If pip itself were subject to a supply chain attack,[^1] any callers of setup-python would be immediately affected during the attack window of opportunity.

Also, updating pip on user level seems pointless when virtual environments are used (which you should), because (AFAIK) venvs are initialized with python's bootstrap copy of pip, not site-packages pip.
However, note that merely not calling setup-python's updated pip does not resolve these concerns, because an attacker might upload only an sdist of pip, which would allow for install-time execution of the hypothetical attack.

To be clear, we all hope that this scenario stays entirely hypothetical, but the point is that setup-python is not following safety best practices here, rsp. does not even allow the caller to do so.

Proposed remediation:

• Add an option to let the caller opt out of pip auto-updating entirely (given that it is pointless when a venv is used).
• Subject the default behavior of auto-updating pip to a dependency cooldown, ideally configurable through an input.
  Suggested default: 3 days, like dependabot, or anything non-zero really.
• When a pip-version is specified, install the given version right away without first updating to latest.

Note that updating pip itself with a cooldown is complicated by the fact that pip versions before 26 do not support --uploaded-prior-to, PIP_UPLOADED_PRIOR_TO etc.
This can basically be worked around by updating to a pinned and hash-checked version first, then updating with cooldown.
The following script shows how to do this: https://github.com/pypdfium2-team/pypdfium2/blob/811faae77f8fc90bc57832bc6400c65fd9f4fbee/utils/update_pip.py

Justification:
Supply chain safety, see the description above.

Are you willing able to submit a PR?

No, I am not a typescript programmer and not familiar with setup-python's internals.

Edit: Submitted https://github.com/actions/python-versions/pull/406 after all, a simple patch to avoid possible setup-time code execution when updating pip. This should stuff a key loophole and allow an aware caller to be unaffected, but otherwise the issue still stands.

[^1]: Hypothetical and hopefully highly unlikely, but no project is per se immune to it, and you have to acknowledge that pip would be a very lucrative target for a supply chain attack, so downstream precautions seem important.