Replies: 1 comment
-
|
No there are not legimate use cases, the expectation is that the |
Beta Was this translation helpful? Give feedback.
0 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
-
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:
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
.whlrelease 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
.pypircfile 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?
Beta Was this translation helpful? Give feedback.
All reactions