Counter-StarJacking feature POC - mention about metainformation stealing via .pypi_acknowledged file

[rakovskij-stanislav]

This PR represents a poc of StarJacking protection feature.

StarJacking on Mitre

I suggest to use a .pypi_acknowledged file to set that GitHub repository is acknowledged that some PyPI packages is connected with it and GitHub repository allows to use star/forks/pr statistics.

.pypi_acknowledged is a plain text file, a list of PyPI project names, one per line. It is a simple concept that looks like requirements.txt without version binding and links.

pypi_acknowledged_example repository represents this feature on GitHub side and also describes how StarJacking corrupts trust mechanisms in opensource.

For example, .pypi_acknowledged has this content:

pypi_acknowledged_example
yet_another_acknowledged_package

Also we have three projects:

1. pypi_acknowledged_example, it sets a proper home page

[project]
name = "pypi_acknowledged_example"
version = "3.4.1"
description = "This is an example package that represents .pypi_acknowledged feature"
readme = "README.md"
classifiers = [
    "Programming Language :: Python :: 3",
    "License :: OSI Approved :: MIT License",
    "Operating System :: OS Independent",
]

[project.urls]
"Homepage" = "https://github.com/rakovskij-stanislav/pypi_acknowledged_example/tree/main"

---

2. try_better_next_time, it abuses statistics of some "popular" project, but the last one is protected by .pypi_acknowledged

[project]
name = "try_better_next_time"
version = "0.0.3"
description = "This is an example package that represents .pypi_acknowledged feature"
readme = "README.md"
classifiers = [
    "Programming Language :: Python :: 3",
    "License :: OSI Approved :: MIT License",
    "Operating System :: OS Independent",
]

[project.urls]
"Homepage" = "https://github.com/rakovskij-stanislav/pypi_acknowledged_example/tree/main"

---

3. just_a_package. It probably links to a proper package, but we just cannot verify it

[project]
name = "just_a_package"
version = "0.0.2"
description = "This is an example package that represents .pypi_acknowledged feature"
readme = "README.md"
classifiers = [
    "Programming Language :: Python :: 3",
    "License :: OSI Approved :: MIT License",
    "Operating System :: OS Independent",
]

[project.urls]
"Homepage" = "https://github.com/pypa/sampleproject"

---

Thus, the introduction of this functionality will make the use of reputation statistics more conscious. A lot of packages use pypa/sampleproject just because it presents in a default packaging guide:

[di]

Thanks for the PR! However, our current plan is to do this based on Trusted Publishers configuration instead: https://github.com/pypi/warehouse/issues/13515

[rakovskij-stanislav]

@di, thanks for your fast reply)

As I can see, Trusted Publishers does not solve the issue of StarJacking. If we will grab the stars from the GitHub repository set in project settings without extra verification, a threat actor can just use pypa/sampleproject. We need some hint from GitHub repo that it knows about certain PyPI package(s).

[di]

The "extra verification" in this case would be whether the given repository has actually been used to publish to PyPI.

[rakovskij-stanislav]

The "extra verification" in this case would be whether the given repository has actually been used to publish to PyPI.

Understood. It seems like a nice feature, despite companies that use self-hosted bitbucket / gitlab for deployment both on github and pypi will be obligated to use github->pypi deployment to have reputation statistics on their pypi pages

[di]

We are planning to support Gitlab (https://github.com/pypi/warehouse/issues/13575) and other providers once they start supporting OIDC federation.

[woodruffw]

Triage: I think this might be close-able, now that we've gone with a verified URLs approach based on Trusted Publishing?