TODO: A zero dependency #python app can be installed with
- git clone
- or download zip,
executed with python -m
But you can't search #pypi for these apps.
These apps have minimal supply chain risk
Are still "installable" in locked down environments
I got people on my team that still can't get uv, pip or pipx to work with Artifactory. (Why don't they just use pipenv, or setuptools or poetry or ...)
But they're more or less unfindable.
#pypi survey
Can this be buried any deeper?
- go to project
- go download files
- view details - Oh look, there are signatures.
Anyhow, back to my original thesis, another anonymous user who may or may not be in control of their github actions (if they didn't run zizmor, that action could literally be anyone), published that package and it came from that server.
Survey on improving the #pypi sidebar today.
I told them I think "verified / Trusted Publisher" means, "the build server used a short lived password"
(thinking more, if metadata is signed but nothing else is, what a weird place to stop. Like, ooh, I trust this metadata, so I trust the unsigned #python wheel?)
We don't know who publishes ANYTHING to pypi.org it is all anonymous. "That build server" isn't exactly what people mean by identity. Sure, it narrows it down.
I fork packages and I don't want to look like I taking credit away from the original author, so I leave their names there. But the UI now makes it look like my published package is somehow *them*. That trust should not extend to my package. People should only trust it if they trust me. Ditto for the 150 contributors who didn't publish the package. (I mean, except if we skip blaming the publisher and blame the person who snuck in a malicious commit)
Don't get me wrong, I'm happy they're thinking about this & and doing the survey.
It is still got a way to go but here is a tool for making the missing #pypi user profile.
But Matt, where do you put the signature or rel=me? In a package!
Pypi is pretty meager for profile info, but you can publish a #python package with a whole website in it.
This is what the static site works like, with light debranding. I left pypi in the name because there are a lot of packages with `pypi-` in the name.
It is yet another "publish a cryptographic signature on two sites to prove you own it"
<at my funeral>: "And I leave my remaining wealth to the first heir to contractually agree with the estate to maintain my 55 #pypi packages and update them forever."
I'm pretty sure that is what companies think open source maintainers do.
I need to create a #pypi package and all the good names are taken. Maybe I should use the same brand generator that everyone in China uses to sell goods on Amazon.
ha funny, Amazon realized they created a problem asking the generics to pick a brand name. "wedontgiveashit" brand probably was taken first
https://sellercentral.amazon.com/brand-name-generator?mon_sel_locale=en_US
Looks like there aren't any issue #python issue/bug trackers that are
- easy to install (eliminates trac, roundup)
- can be found in #pypi (is just bad SEO?)
- isn't actually mostly a github clone (Kallithea)
- isn't actually help desk software (call center & tickets to fix printers I guess.)
Really? I'm torn between wanting to write trac-init, roundup-init and just writing what should be yet-another-issue-tracker.
This website accuses common libraries of being hit by malware attacks without substantiating evidence.
Couldn't find reports of #orjson being highjacked, just this websites assertion.
The same website calls my apps vulnerable and malicious, also, doesn't exactly say why.
This site sees yanking as malicious. Kind of damned if you do/don't. What if you publish a package that is
- broken
- has a vulnerability
- and you *know* that there is 0 usage for that package because it is an app & has negligible downloads
Yanking is just assumed to be a lpad attack on the ecosystem.
Don't install packages if they're published just a moment ago, wait a day or week or two.
https://blog.yossarian.net/2025/11/21/We-should-all-be-using-dependency-cooldowns
"The PSF blog post says the plan was to build tools for automating [ #pypi ] package reviews “rather than the current process of reactive-only review."
This would be a fun crowdsourcing thing to do. It would have the same problems as bug bounties and CVE reports from the public, but it would be fun to write one of these.
IDEA: funding.yml files and the like should all mention #PSF as well.
Me as someone who should know by now
- wasn't sure if membership to PSF pays for #pypi
- what a fair "price" is for using pypi to download or host (enterprise competitors are $$$)
If the US gov't is going to add political litmus tests for supporting tech infrastructure, we need to be thinking about alternative funding.
IDEA: a #python package, but it acts as my #pypi profile page.
This idea isn't all that novel, (package-as-resume) but this time I want to make it easy for people to copy & useful on installation. And of course it is ironic to install a package a way to get info about a user as a trust building exercise. I guess if I got it to run in pyscript that would be a good exercise.
Do you wish you could remove certain libraries from the #python standard library? Sort of like CAS in .NET?
Well I got you covered.
Not a replacement for docker. Works like pytest-socket.
Anyhow, looking forward to examples of exploits, which I imagine would be un-monkeypatching or just using other libraries.
Still I think this would be a nice way to seal apps you distribute against highjacked 3rd party libraries that weren't specifically targetting this defense.
And why is this called `hermetic-seal?` ? Well after searching for a perfect name I picked `hermetic`, which is 404 on pypi, free to take? Nope, if you register trusted publisher for that name #pypi says it is **taken**!
It's alive!
`skip-trace` Track down who owns that #pypi package. Name from finance industry, a "skip trace" is finding people who owe you money.
**PROS**
- inspects source files in package (useful if all links are missing or 404)
- Basic NER
- Checks for email addresses, socials
- Checks github contact info
- Works on my machine
**CONS**
- Spacy requires non-standard installation
- You need a github key
- I got ideas for more collectors (home page contents, PKG_INFO)
#pypi #python package maintainers are under attack.
https://www.theregister.com/2025/09/24/pypi_phishing_attacks/
#python and #pypi supply chain mitigation for *apps*
What we (and npm and cargo and so on) need is pipx, except it runs that app in a docker container.
So I wrote a little script to generate a docker file, transferred the credentials for a secure python proxy to it, build and run the docker file.
The docker part was hard, but 10% of users, 1% of the time would be able to do it, but that wasn't the worst.
The private credential repo proxy was the hardest to configure. pip and uv really don't want to use anything other than pypi directly. Better to make sure no one uses a corporate proxy than to just trust pypi.org
malicious typo squats? in the news daily.
MITM? That is just life man, every organization is running a MITM against all the staff too see what they're up to. pip and uv have the wrong threat model. UX tricks to drive proxy use to 0 isn't improving security.
Features this needs
- auto discover if user has docker or podman
- auto discover credentials in context (machinewide pip.conf and translate to unix and move into the container)
- use local website or tkinter to handle user prompts because if only the 1% of 1% of users comfortable with cli use this, then it is pretty thin security. Heck even pipx has pretty low adoption.
And by proxy I mean like these, not HTTP proxies which don't have pypi security features
Artifactory
AWS CodeArtifact
Google Cloud Artifact Registry
GitHub Packages
GitLab Packages
Sonatype Nexus
Cloudsmith
Buildkite Package Registries
Now #golang has a supply chain security problem.
Github actions, terraform, go.... hmm, what do we got in common here.. treating git endpoints as trusted. But git endpoints can't have any central authority to check for malicious code! At least at #pypi you can report a package as malicious.
https://www.youtube.com/watch?v=EyO_SMl2YBk&ab_channel=CodeHead
Well that was weird. I offered to be maintainer to 2 libraries and the maintainer made me a collaborator on #pypi. Then without warning I'm removed as collaborator. His git repos are archived - https://github.com/Robpol86/terminaltables
https://github.com/Robpol86/colorclass
I was just doing the minimal maintenance: #python version updates, wheels.
Should I
Archived poll
15 voters
#pypi should have a filter for project size. When the readme is longer than the code, it is a sign that maybe
- it shouldn't be a library (vendorize those 10 lines of code)
- it is an outline for an idea of a gist, not a library or app
I mean this is clever, but it is a long way from, say Moodle,
https://github.com/BrokenShell/MultiChoice/blob/master/MultiChoice.py
(I'm picking on pypi's search functions, not this dev. If I wanted a gist for a prompt like prompt toolkit, this would be perfect)
#pypi paper - Machine learning can find malicious packages because they just look weird (compared to other packages, but similar to each other, even across programming languages)
IDEA: a #pypi tool that lists who supports all your packages, both direct and indirect.
Security, after you follow the chain of causes, keeps coming back to a problem of authentication and trust. Do you know who did that and do you trust them?
A package name just means someone gave a package a name. Doesn't help all the identity info is self asserted.
#pypi #python - Did someone already write a tool to front run `safety` or `pip-audit` before anything is installed? I guess something like "poetry lock" and then audit the files for suspicious situations, like CVEs or the repo was created yesterday or the package was published yesterday.
Installing everything then running `safety` imho has always been !@#$!@$ stupid because the malicious code runs during install.
Keep continuously slamming that barn door after the cows left to improve your cybersecurity stance.
I'm going to have to rename my side project. #pypi is going to frown when I delete the old project.
Lazy RAG:
I made a GPT (a system prompt) that tells ChatGPT to use it's own info to think of #pypi packages that match my needs, then to search bing using `domain:pypi.org possible-package` to check if it really exists
Here is an example looking for version bumping. I haven't revisited bumpversion because when I last tried, the tool was like: here write your own f*king regex and provide it to the tool, I think any tool that delegates the hard stuff to the end user is 💩
https://chat.openai.com/share/20617aea-ce97-4282-b556-e54225dfe4a7
Why do I ask it to use it's own internal knowledge first? Because if you ask it to do a bing search it will use your key words, then hyperfixate on bings top 5 results. You now have the worlds most expensive interface to bing's top 5 results and you've lost the ability to do semantic search.
Here is the link to the GPT. https://chat.openai.com/g/g-b2eHsARNh-pypi-package-researcher
When someone republishes an identical (?) copy of a major package under their own name on #pypi, that's probably malicious right? This is a variation on typosquatting.
Today I learned about the inspector website, browse the contents of a package before you install it! Much easier than the download, unzip, etc.
I updated most of my #pypi project to use "trusted publisher"
I can't figure out how to get an "environment" to only allow deployment from tags (which bizarrely #github treats as "branches") so I instead add an approver step and potentially all builds can be deployments, but only if I click OK.
Completely invisible...
So I can use the "Trusted Publisher" feature to publish from github without secrets, but no obvious clue on #pypi to say that the package was uploaded via Trusted Publisher.
https://github.com/matthewdeanmartin/markpickle/blob/main/.github/workflows/build.yml#L36
#pypi is doing the right thing and requiring 2 factor for all package uploading. It should be much harder to take over abandoned packages by using leaked passwords. I guess I also need to learn how to do the 2nd factor, or maybe just switch my publishing to github actions
#pypi should add a way to star packages as a quality signal.
Also, for the library I published yesterday there should be a "sensible chuckle" button for the funny ones.
#python The new #pypi blog lacks commenting (but Github has comments on the commits!). It also lacks a feed.
You'd think there would be a standalone free product to create a feed from HTML by now. I'll have to look for one later. (feedly has one, but it cost $)
https://blog.pypi.org/posts/2023-03-21-welcome-to-the-pypi-blog/
Ever want to turn json into markdown? I wanted to and couldn't. So I made a python-to-markdown serialization library. Handles some but not all types.
```
>>> loads("- a\\n- b\\n - c\\n")
['a', 'b', 'c']
```
and
```
>>> dumps([1,2])
'- 1\\n- 2\\n'
```
https://pypi.org/project/markpickle/0.2.0/
And by couldn't I mean, I couldn't without like, importing the json to python, walking the graph of the dict and deciding how to turn each key and value into markdown.
Today's pet #pypi peeve
Package Name != main module name != CLI command name != Github repo name
Especially when there is just one of each.
I'm looking at you linkcheckmd (3 other names elided)
https://github.com/matthewdeanmartin/linkchecker-markdown/blob/main/setup.cfg
#pypi man, why do we bother with passwords if people are just going to post them on github?
https://github.com/search?q=path%3A.pypirc%20password&type=code