PyPI Prohibits inbox.ru email domain registrations
blog.pypi.org
blog.pypi.org
However, blocking an email domain will dissuade only the lowest effort attacker. If the abusers think slopsquatting is effective, they'll easily be able to find (or create) an alternative email provider to facilitate it.
And assuming that the attacks will persist, sometimes it's better to let them keep using these massive red flags like an inbox.ru email so that it remains a reliable way to separate the the fraudulent from legitimate activity.
That applies from user experience: “how do I get user to click button”, to security “how do I lock things down enough to prevent most attacks I can think of”, to hardware design: “how do I ensure the chipset won’t melt down under really stupid software conditions”
Starting with the low hanging fruit isn’t always the worst option. Sometimes it’s enough to dissuade people to give up.
* 2025-06-09 first user account created, verified, 2FA set up, API Token provisioned
* 2025-06-11 46 more user accounts created over the course of 3 hours
* 2025-06-24 207 more user accounts created over the course of 4 hours
I do run https://bademails.org , powered by the same disposable-email-domains project, and I'll be the first to say that it only cuts out the laziest of attempts. Anyone even slightly serious has cheap alternatives (25 to 100+ accounts for $1 on popular email hosts).
There has to be a level of community validation for anything automatically installable. The rest of the world needs to have started out by pulling and building/installing it by hand and attesting to its usefulness, before a second level (e.g. Linux distro packagers) decide that it's good software worth supplying and supporting.
Otherwise, at best the registries end up playing whack-a-mole with trickery like this. At worst we all end up pulling zero days.
Debian figured this out three decades ago. Maybe look to them for inspiration.
Last I checked, we pay $0 beyond our normal cost for bandwidth, and their end of the bandwidth is also subsidized.
There are a handful of commercial competitors in this space, but in my experience this ends up only being valuable for a small % of companies. Either a company is small enough and it wants to be agile and it doesn't have time for a third party to vet or review packages they want to use. Or a company is big enough that it builds it's own internal solution. And single users tend to get annoyed when something doesn't work and stop using it.
But it's still broken.
[1] Frankly even Rust has this disease with the way cargo is managed, though that remains far enough upstream of the danger zone to not be as much of a target. But the reckoning is coming there at some point.
It's not even cheap, it's just possible to get companies to donate the resources to sustain it: https://dustingram.com/articles/2021/04/14/powering-the-pyth...
What it is is feasible, and IMO the alternative you're suggesting is infeasible under our current model of global economics without some kind of massive government funding.
> you're strongly incentivized to root your users simply because if you don't your competitors will
Python is not rooting it's users, this is hyperbole.
for pypi that means raising funds that we can contribute to.
so instead of arguing that the PSF doesn't have the resources, they should go and raise them. do some analysis on what it takes, and then start a call for help/contributions. to get started, all it takes is to recognize the problem and put fixing it on the agenda.
The PSF has raised resources for support; the person who wrote this post is working full-time to make PyPI better. But you can't staff your way out of this problem; PyPI would need ~dozens of full time reviewers to come anywhere close to a human-vetted view of the index. I don't think that's realistic.
I disagree with this analogy, both those libraries have complex and nuanced implementation details which make forking difficult to work in a compatible way. PyPI does not, you can host a simple index with existing libraries and have 100% compatibility with all Python package installer tools.
And YET, openssl has been forked by companies a bunch of times exactly because it lacks resources to do significant security analysis of it's own code.
> for pypi that means raising funds that we can contribute to.
PyPI accepts funds, feel free to donate.
> so instead of arguing that the PSF doesn't have the resources, they should go and raise them. do some analysis on what it takes, and then start a call for help/contributions. to get started, all it takes is to recognize the problem and put fixing it on the agenda.
This is all already being done, it appears like you haven't done any research into this before commenting on this topic.
It seems odd to pitch suggestions for other things they ought to do but then couch it with “well I’m not being serious” in a way that deflects all actual discussion of the logistics of your suggestion.
> in a way that deflects all actual discussion of the logistics of your suggestion
You seem to be mistaken there: I very much welcome a discussion on it. Keyword being "discussion". Just let's not expect an outcome anything more serious than "wow I sure came up with something pretty silly / vaguely interesting". Or put forward framings like "I'm telling them what to do or what not to do".
if anyone can just sign up then how can i trust that? being maintained by the PSF they should be able to come up with the funding to support a proper process with enough manpower to review submissions. seems rubygems suffers from the same problem, and the issues with npm are also well known.
this is one of those examples where initially these services were created with the assumption that submitters can be trusted, and developers/maintainers work without financial support. linux distributions managed to build a reliable review process, so i hope these repositories will eventually be able to as well.
By whom? I've had a decent number of projects of mine included in Linux distributions, and I don't think the majority of my code was actually reviewed for malware. There's a trust relationship there too, it's just less legible than PyPI's very explicit one.
(And I'm not assigning blame for that: distros have similar overhead problems as open source package indices do. I think they're just less visible, and people assume lower visibility means better security for some reason.)
yes, there is a trust relationship, but from what i have seen about the submission process in debian, you can't just sign up and start uploading packages. a submitter receives mentoring and their initial packages are reviewed until it can be established that the person learned how to do things and can be trusted to handle packages on their own. they get GPG keys to sign the packages, and those keys are signed by other debian members. possibly even an in person meeting is required if the person is not already known to their mentors somehow. every new package is vetted too, and only updates are trusted to the submitter on their own once they completed the mentoring process. fedora and ubuntu should be similar. i don't know about others. in the distribution where i contributed (foresight) we only packaged applications that were known and packaged in other distributions. sure, if an app developer went rogue, we might not have noticed, and maybe debian could suffer from the same fate but that process is still much more involved than just letting anyone register an account and upload their own packages without any oversight at all.
And isn't the Debian mentoring and reviewing merely about checking if the package is properly packaged into the Debian format and properly installs and includes dependencies etc?
I don't think there is anything actually stopping some apparently safe code from ending up in Linux distros, except the vague sense of "given enough eyeballs, all bugs are shallow", i.e. that with everyone using the same package, someone is going to notice something, somehow.
Someone else.
To be clear: I find the Debian maintainers trustworthy. But I don't think they're equipped to adequately review the existing volume of a packages to the degree that I would believe an assertion of security/non-maliciousness, much less the volume that would come with re-packaging all of PyPI.
(I think the xz incident demonstrated this tidily: the backdoor wasn't caught by distro code review, but by a performance regression.)
the difference to pypi/npm/rubygems etc is that nobody would upload a package to a personal repo with a dozen dependencies from other personal repos. when i install a copr package i can be sure that all dependencies are either from the trusted fedora repo or from that same personal repo.
that means i only need to trust that one developer alongside the official distribution. unlike npm or pypi where i have to trust that each submitter vetted their own dependencies, or vet them myself, which is also unrealistic.
Also what I meant is a "standard execution environment", so that the developer doesn't need to make a separate version for each Linux distribution, and doesn't have to make repositories.
however that is completely besides the point because we are really talking about improving trust with pypi and npm and the like. sandboxing here is simply not possible because these are mostly libraries to be used for development of larger apps.
the approach distributions are using now would be useful here.
That's not the model though. Your packages weren't included ab initio, were they? They were included once a Debian packager or whoever decided they were worth including. And how did that happen? Because people were asking for it, already having consumed and contributed and "reviewed" it. Or if they didn't, an upstream dependency of theirs did.
The point is that the process of a bunch of experts pulling stuff directly from github in source form and arguing over implementation details and dependency alternatives constitutes review. And quite frankly really good review relative to what you'd get if you asked a "security expert" to look at the code in isolation.
It's not that it's impossible to pull one over on the global community of python developers in toto. But it's really fucking hard.
The thing is, I don't think that's what's happening in 2025. I think that might have been what was happening 20 years ago, but I didn't experience any pushback over my (very large) dependency tree when my projects were integrated. Lots of distros took a look at it, walked the tree, rolled everything up, and called it a day. Nobody argued about dependency selection, staleness, relative importance, etc. Nobody has time for that.
> It's not that it's impossible to pull one over on the global community of python developers in toto. But it's really fucking hard.
I don't think this is true; at the periphery, ~nobody is looking at core dependencies. We can use frequency of "obvious" vulnerabilities in core packages as a proxy for how likely someone would discover an intentional deception: CVE-2024-47081 was in requests for at least a decade before anybody noticed it. Last time I checked, the introduction-to-discovery window for UAF vulnerabilities in Linux itself was still several years.
(This is true even in the simplest non-code sense: I maintain a lot of things and have taken over a lot of things, and nobody notices as long as the releases keep coming! This is what the Jia Tan persona recognized.)
And. It. Failed. Debian caught it.
So no. Not perfect. But pretty good, and I trust them and their track record. That's a very different environment than "Here guys, we'll send your code all over the world. But no Russian emails please. Thx."
(Plus, my recollection is that Debian didn’t catch it. It was caught by a downstream user.)
The bigger problem is that people want to have their cake and eat it too: they want someone else to do the vetting for them, and to receive that added value for no additional cost. But that was never offered in the first place; people have just sort of assumed it as open source indices became bigger and more important.
That is precisely the broken part. There are thousands of packages in my local python venv. No, I didn't "vet" them, are you serious? And I'm a reasonably expert consumer of the form!
That's true in the sense that distros tend to provide digital signatures. But we're talking asserting the actual security of packages, not just that they were quickly looked at by a trusted party.
And again, that's not somehow blameworthy: they're providing significant value even without asserting the security of packages.
(And don't take my word for this: take it from the distro maintainers in this very thread, as well as elsewhere[1].)
[1]: https://www.reddit.com/r/linux4noobs/comments/1c6i3je/are_al...
I might find the likes of Snyk somewhat annoying when I'm required to have them audit projects at work (they aren't as good as Renovate or even Dependabot at raising version bumps, and most of the alerts are false positives for our environment) but I mostly appreciate that they exist.
This is easy to game, and in some ways has been pre-gamed. So it wouldn't really be a measure of validation, but would be interesting to see.
You can use open-source security analytics (1) to detect fraudulent accounts instead of blocking domain names. Blocking domains only shows your system is fragile and will likely just shift the attackers to use other domains.
Feel free to contact us if you need assistance with setup.
> Download a zip file and extract it "where you want it installed on your web server"
The requirements mention apache with mod_rewrite enabled, so "your web server" is a bit vague. It wouldn't work with e.g. `python -m http.server 8000`. Also, most software comes bundled with its own web server nowadays but I know this is just how PHP is.
> Navigate to http://your-domain.example/install/index.php in a browser to launch the installation process.
Huh, so anyone who can access my web server can access the installation script? Why isn't this a command line script, a config file, or at least something bound to localhost?
> After the successful installation, delete the install/ directory and its contents.
Couldn't this have been automated? Am I subject to security issues if I don't do this? I don't have to manually delete anything when installing any other software.
If there is an example of another approach, I will gladly take it into account.
Maybe a decade ago. Look into composer.
In my recent experience, you have about 3 seconds to lock down and secure a new web service: https://honeypot.net/2024/05/16/i-am-not.html
Where did you "create" this subdomain, do you mean the vhost in the webserver configuration or making an A record in the DNS configuration at e.g. your registrar? Because it seems to me that either:
- Your computer's DNS queries are being logged and any unknown domains immediately get crawled, be it with malicious or white-hat intent, or
- Whatever method you created that subdomain by is being logged (by whoever owns it, or by them e.g. having AXFR enabled accidentally for example) and immediately got crawled with whichever intent
I can re-do the test on my side if you want to figure out what part of your process is leaky, assuming you can reproduce it in the first place (to within a few standard deviations of those three seconds at least; like if the next time is 40 seconds I'll call it 'same' but if it's 4 days then the 3 seconds were a lottery ticket -- not that I'd bet on those odds to deploy important software, but generally speaking about how aggressive-or-not the web is nowadays)
I can definitely reproduce this. It shocked me so much that I tried a few times:
1. Create a new random hostname in DNS.
2. `tail -f` the webserver logs.
3. Define an entry for that hostname and reload the server (or do whatever your webserver requires to generate a Let's Encrypt certificate).
4. Start your stopwatch.
We also use CT logs at work to discover subdomains that customers forgot about and may host vulnerable software at (if such broad checks are in the scope that the customer contracted us to check)
3 seconds.
"Obviously", the server should not be accessible from the public Internet while you're still doing setup. I assume it should still behind a firewall and you're accessing it by VPN. Only after you're happy with all the configuration and have the security locked down tight would you publish it to the world. Right?
- The application code itself and system configs are modifiable by the web handler itself. This is needed to allow web-based "setup.php" to work, but also means that any sort of RCE is immediately "fatal" - no need for kernel/sandbox exploit, if you can get PHP to execute remote code you can backdoor existing files as much as you want.
- The "logs", "tmp", "config" etc.. directories are co-located with code directory. This allows easy install via unzip, but means that the code directory must be kept accessible while operation. It's not easy to lock it down if you want to prevent possible backdoors from previous options.
Those install methods have been embraced by PHP community and make exploits so much easier. That's why you always hear about "php backdoors" and not about "go backdoors" or "django backdoors" - with other languages, you version-upgrade (possibly automatically) and things work and exploits disappear. With PHP, you version upgrade .. by extracting the new zip over the same location. If you were hacked, this basically keeps all the hacks in place.
Kinda weird to see this from some self-claimed "security professionals" though, I thought they'd know better :)
However tirreno shouldn't be public-facing anyway. Production apps forward events via API on local network, security teams access dashboard over VPN.
Perhaps we will add this recommendation to the documentation to avoid any confusion. Thanks for the clarification.
> but I haven't used any PHP for over a decade
This isn't modern PHP, this is the traditional installation method that I used also a decade ago. The only thing that could be older about it is to have a web-cron instead of a proper system cron line. Modern PHP dependency installation is to basically curl|bash something on the host system (composer iirc) rather than load in the code under the web server's user and running the install from there, as this repository suggests. Not that the parent comment is wrong about the risks that still exist in being able to dynamically pull third-party code this way and hosting secrets under the webroot
Like with IP ranges that send a lot of spam/abuse, it's the provider's space in the end. If the sender has no identification (e.g. User-Agent string is common for http bots) and the IP space owner doesn't take reasonable steps, the consequence is (imo) not to guess who may be human and who may be a bot, but to block the IP address(es) that the abuse is coming from. I remember our household being blocked once when I, as a teenager, bothered a domain squatter who was trying to sell a normal domain for an extortionary price. Doing a load of lookups on their system, I couldn't have brought it down from an ADSL line but apparently it was an unusual enough traffic spike to get their attention, as was my goal, and I promptly learned from the consequences. We got unblocked some hours after my parent emailed the ISP saying it wouldn't happen again (and it hasn't)
You don't have to look very far on HN to see the constant misclassifications of people as bots now that all the blocking has gotten seven times more aggressive in an attempt to gatekeep content and, in some cases, protect from poorly written bots that are taking it out on your website for some reason (I haven't had the latter category visit my website yet, but iirc curl/Daniel mentioned a huge outbound traffic volume to one scraper)
However, email accounts could be stolen, and this makes the email provider a victim as well.
This particular case sounds very simple, and I'm quite confident that if we dig further, it's highly possible that all accounts use some pattern that would be easy to identify and block without hurting legitimate users.
Edited to add:
> this makes the email provider a victim as well
Sure, but they have to deal with a hijacked account anyway, better to tackle it at the source. I'm also not saying to block the whole provider right away, at least not if you can weather the storm for a business day while you await a proper response from their side, just to use blocks when there is nobody steering the ship on their end
This project has an allowlist you can submit a PR to so it doesn't get sucked back in every time people submit outdated lists of free email provider domains.
I've sent dozens of PR's to de-list my domains on various projects across Github and it's like fighting the sea, but the groups making opensource software to use these lists are at least very apologetic and merge the PR's quickly.
However, the biggest ASSHOLES are Riot Games. I've reached out to and they will not ban new user registrations on my domains. I eventually just had to block all the new account registration emails for League of Legends I was getting in my catch-all. The maintainer of the tool people were using to make new accounts was very responsive and apologetic (quickly merged my PR) but it doesn't stop people who used the old versions of it from continuing.
You can check it out with: pip install safety && safety init
The kind of validation being discussed here would take way more than “a staffer”.
I'm insisting that even the barest minimum of human/manual involvement solely on account signup would be a major security improvement.
It would be exhausting to have to audit your entire dependency tree like your life depended on it just to do the most mundane of things.
The thing you’re suggesting is outright not possible given the staffing that the Python maintainers have.
(So much of supply chain security is people combining these two things, when we want both as separate properties: I both want to know a package's identity, and I want to know that I should trust it. Knowing that I downloaded a package from `literallysatan.com` without that I should trust `literallysatan.com` isn't good enough!)
Any time you introduce humans manually reviewing things, the attackers win instantly by just spamming it with garbage.
> See a previous post for a previous case of prohibiting a popular email domain provider.
Although: I don't think the kind of developers that use low quality email providers like that follow HN.
Edit: Remember those 7+ hours back in 1999 when all Microsoft Hotmail accounts were wide open for perusal?
https://time.com/archive/6922796/how-bad-was-the-hotmail-dis...
> Yesterday a Swedish newspaper called Expressen published the programmer’s work, a simple utility designed to save time by allowing Hotmail users to circumvent that pesky password verification process when logging into their accounts. The result? As many as 50 million Hotmail accounts were made fully accessible to the public. Now that the damage has been done, what have we learned?
> It wasn’t until the lines of code appeared in Expressen that people realized how vulnerable Hotmail really was. The utility allowed anybody who wanted to to create a Web page that would allow them log into any Hotmail account. Once the word was out, dozens of pages such as this one were created to take advantage of the security hole. Unfortunate programmers at Microsoft, which owns Hotmail, were rousted out of bed at 2 AM Pacific time to address the problem. By 9 AM Hotmail was offline.
https://www.theregister.com/1999/08/30/massive_security_brea...
https://www.theguardian.com/world/1999/aug/31/neilmcintosh.r...
> Please enter the phone number you'll use to sign in to Mail instead of a password. This is more secure.
The blog post references [0] which makes it seem like the maintainers do, in fact, just ban any email providers that attackers use instead of trying to solve the issue.
[0] https://blog.pypi.org/posts/2024-06-16-prohibiting-msn-email...