PyPI Prohibits inbox.ru email domain registrations

Our entire profession is “how can we make thing difficult enough to not be used incorrectly”

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.

Neighbors? No, household; the ISP can't see into the house's network which MAC address did it, so they blocked the subscriber line that served my parents' household back when I lived with them (it was partially blocked actually: you could still visit info pages about the block on the ISP website and contact them by email)

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

I kinda understood I was missing "something" when I commented but I haven't used any PHP for over a decade and honestly it looked very well you said the rest... Thanks for the clarification. Very unfamiliar with modern PHP.

Fair critique on traditional PHP deployment.

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.

Yes, Matomo/Piwik, WordPress, and ProcessWire have more or less the same installation steps, but maybe we missed something along the way.

The instructions aren't all that unusual for PHP software, especially those that target shared hosting, but are unusual compared to most other software.

> 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.

composer install should be pretty much what one needs nowadays. Any installing scripts (although you really shouldn’t) can also be hooked into it.

I've been down that road before. Blocking Outlook and Protonmail filters out 0% of legitimate users and 75% of bots. You do what you can so you're not always 1 step behind.

I know a bunch of sites who do that and the problem is usually that register emails get flagged by outlook and never arrive, causing a lot of support burden. Easier to then nudge people into the direction of Gmail or other providers that don't have these issues.

Murky security model for domain validation aside, how does that ensure the honesty of the uploaded package?

(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!)

That’s basically no validation at all. Python doesn’t even have that kind of namespacing to need to validate.

The kind of validation being discussed here would take way more than “a staffer”.

On re-read, I think we're in agreement -- what you're saying is "broken" is me saying "people assuming things they shouldn't have." But that's arguably not a reasonable assumption on my part either, given how extremely easy we've made it to pull arbitrary code from the Internet.

Just have faith in Linus' Law.

Do you have a serious pitch?

> not reviewing submissions is a big problem. i know i can trust linux distributions because package submissions are being reviewed. and especially becoming a submitter is an involved process.

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.)

> And we're collectively paying too much for a crap product as it stands.

Last I checked, we pay $0 beyond our normal cost for bandwidth, and their end of the bandwidth is also subsidized.

If you want to offer a PyPI competitor where your value is all packages are vetted or reviewed nothing stops you, the API that Python package installer tools to interact with PyPI is specified: https://packaging.python.org/en/latest/specifications/simple...

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.