How can we prevent users publishing their credentials by accident?

[orf]

Hello!

For a few years I've been maintaining a project that mirrors code released on PyPI into a series of Github repositories. Unfortunately, there are a large volume of users who have accidentally packaged and released credentials in their PyPI packages, which is then picked up by Github's secret detection.

This is great, because Github notifies the user and also triggers processes to revoke the leaked token by notifying the provider, but I'd like to try to use some of this data to start a conversation about how we can improve the state of affairs and prevent users from publishing credentials in the first place.

I've eyballed a few detected credentials from a recent repository, these where released on PyPI between 2026-01-16 and 2026-01-23, and have all been automatically revoked by Github and the users notified by email about their appearance:

• .env file with a PyPI token
• .envrc with a PyPI token
• pypirc file with a pypi token
• some MCP file with a github token
• another one
• and another one

There are many thousands of other such instances that appear in PyPI releases, these are a few that I just wanted to quickly share. I'm creating this issue here because in each of these cases the corresponding .whl release was packaged by hatchling (here and here for example).

I'd love to hear a maintainers take on this: it's a thorny issue, and I'm not suggesting that we embed some kind of secrets detection into a build system, but are there any legitimate use-cases for a user to include a .pypirc file in the root of their project while building?

Perhaps including a small denylist in hatch that would prevent the user from creating a release containing these accidentally included files would be a good solution?

Nothing is perfect, but it could be a start?

[cjames23]

No there are not legimate use cases, the expectation is that the .pypirc is found in the $HOME directory not pulled into the project root directory. See this code in terms of hatch and the PyPA docs on .pypirc All of the examples at least given here are AI slop which I think is a bigger discussion than just hatchling solving this for anything using hatchling. And as you said I am not sure that we are going to want to implement full on secret detection inside hatchling.

[SuperPauly]

Why is there no GitHub Actions setup to scan for secrets before it pushes to pypi?

All packages should be signed by the author & scanned before it's uploaded to pypi repo.

Given Python Software Foundation License Version 2 is an open source like license and it's a part of the Python Software Foundation nonprofit but most importantly it's a public repo. This means GitHub enables free GitHub Action minutes.

How come they're not being used?

---

@orf Secret detection is hard, I hacked this script together in an hour.

It works like this:

• Searches for key pairs in UTF-8 and ASCII files with the delimiters ':', '=', 'dict.set()' & 'dict["key"]'.
• Checks if the key name is in KEYWORDS (case insensitive).
• Checks if the value is a string.
• Ignores UUID's.
• If the key is in KEYWORDS it then uses entropy to check if the str value is greater than 0.9. (General API keys are, this is considered production safe)
• if it detects it prints.

There is a bunch of CLI args too. It can scan whole dirs, kinda shocked myself when I scan my $HOME 😅. Never knew where certain apps hid their keys. Now I do!

[cjames23]

Why is there no GitHub Actions setup to scan for secrets before it pushes to pypi?
All packages should be signed by the author & scanned before it's uploaded to pypi repo.
Given Python Software Foundation License Version 2 is an open source like license and it's a part of the Python Software Foundation nonprofit but most importantly it's a public repo. This means GitHub enables free GitHub Action minutes.
How come they're not being used?

This is not really relevant to this discussion, hatch/hatchling cannot force anyone who is producing artifacts to use any specific Github Action. These artifacts are not published by us directly they were published by someone else but happened to use hatchling as the build backend.

[orf]

Indeed, discussion of github actions or secret scanning isn't relevant here. The issue at hand is simply this:

❯ tree
.
├── .gitignore
├── .pypirc
├── pyproject.toml
├── src
│   └── foo
│       └── __init__.py

❯ hatchling build
[sdist]
dist/foo-0.1.0.tar.gz

[wheel]
dist/foo-0.1.0-py3-none-any.whl

❯ tar tvf dist/foo-0.1.0.tar.gz
-rw-r--r--  0 0      0           7 Feb  2  2020 foo-0.1.0/.pypirc
-rw-r--r--  0 0      0           0 Feb  2  2020 foo-0.1.0/src/foo/__init__.py
-rw-r--r--  0 0      0         115 Feb  2  2020 foo-0.1.0/.gitignore
-rw-r--r--  0 0      0         250 Feb  2  2020 foo-0.1.0/pyproject.toml
-rw-r--r--  0 0      0         139 Feb  2  2020 foo-0.1.0/PKG-INFO

I simply don't think files like .pypirc or .env* should be included in a sdist at all, regardless of the .gitignore rules.

We also have to be conscious that Python users come in all shapes and sizes - I don't believe that saying "they should be using trusted packaging with a github action", "they are not following best practices" or just "they shouldn't have a .pypirc file here" is a good solution. It's the users not following best practices (due to being unfamiliar with Python, the packaging ecosystem or simply not aware) that are the ones most susceptible to these issues and the ones that are most impacted by it.

Furthermore, the evidence shows that users are publishing these kinds of files by accident - it's not theoretical. We obviously can't catch all cases, but that doesn't mean that we shouldn't try to catch the common ones.

[cjames23]

I am not opposed to adding logic that prevents pyirc files from being included in artifacts produced by hatchling. But in terms of looking for other types of files that might contain credentials that is unlikely to get considered because that becomes a slippery slope as to what is included and excluded from our logic.