[HN Gopher] PyPI new user and new project registrations temporar...
___________________________________________________________________
PyPI new user and new project registrations temporarily suspended
Author : jonbaer
Score : 85 points
Date : 2023-05-20 20:04 UTC (2 hours ago)
(HTM) web link (status.python.org)
(TXT) w3m dump (status.python.org)
| efitz wrote:
| > The volume of malicious users and malicious projects being
| created on the index in the past week has outpaced our ability to
| respond to it in a timely fashion, especially with multiple PyPI
| administrators on leave.
|
| People suck and that is why we cannot have nice things.
| donio wrote:
| Yes, people suck and I wish they didn't but the other side of
| the problem is that the centralized flat-namespace model of
| PyPI is especially vulnerable.
| Hnrobert42 wrote:
| The shame of it is that a tiny, tiny, tiny fraction of people
| really suck. The number of people involved is probably less
| than a thousand. (This is my totally uninformed speculation.)
| [deleted]
| miohtama wrote:
| It's calle Tragedy of Commons
|
| https://en.m.wikipedia.org/wiki/Tragedy_of_the_commons
|
| One solution would be have a minimum payment or a trusted
| sponsor in order to register a new package. A minimum trust
| score through well-known community persons, or reduce spam by
| payments.
|
| On the root cause why people suck is that different cultures
| and different people have different values. For many people
| making money by spamming is not an issue in their own internal
| value system. Thus, it is better to be tackled by making spam
| unprofitable.
| Severian wrote:
| I've been very cautious the last couple of years due to these bad
| actors when looking at packages that might suit my needs. If
| there is no online presence of the source code (git anything,
| zips/gzs, etc), multiple packages submitted in a short time
| frame, or a greater than normal amount, an/or a derivation/plugin
| of a popular package it's usually a no-go.
|
| For those that I do possibly trust, I then download the package
| (pip download) and review it. Doing a quick regex for URLs or
| exec() calls helps, but I probably should use something like
| guarddog (https://github.com/DataDog/guarddog)
| blibble wrote:
| namespacing? what's that
| throwaway892238 wrote:
| Methods to deal with malicious actors in your system:
|
| - Require toilsome identity verification. Things that are in
| short supply and are difficult to get and uniquely identify a
| person. Examples include a phone number, credit card, driver's
| license, mailed letter, etc.
|
| - Require a referral, both for accounts and for new packages.
| Don't allow a signup unless the user has a referral code
| generated by another user with good karma. This isn't fool-proof,
| as a user that does get an account can then generate more
| accounts. But it makes it easier to revoke them en-masse, and
| forces users to be more scrupulous about who they refer, as you
| can block the referrer as well as the malicious user.
|
| - Require community review, both of new users, and new packages.
| New users/packages are sent to a mailing list of moderators and
| somebody has to approve it, but someone who notices a problem can
| also reject it, even after it's been mistakenly approved. Slower,
| but there's more eyeballs to spot malicious stuff. This is more
| common among open source projects. (Growing your moderator list
| is important, as well as automating as much of the review process
| as possible; obviously PyPI currently has a shortage of
| moderators, but they should have a huge number of them by now!)
|
| - Don't allow new users to do certain things until enough time
| has passed or they have accrued enough karma points. May require
| fixing bugs, answering questions, etc; work which benefits the
| community and most malicious actors wouldn't invest the time and
| effort in. Again not fool-proof, but definitely increases the
| time and difficulty for successful attacks.
|
| - Captchas. These can obviously be worked around, but are a
| minimum-effort way to avoid bot signups.
|
| For better defense-in-depth, combine multiple methods.
| nonethewiser wrote:
| What about some testnet that allows people to push things up as
| a test? That seems like a valid need but a source of lots of
| garbage at the same time.
| mplewis wrote:
| This is what https://test.pypi.org/ is for.
| Hnrobert42 wrote:
| These are good suggestions. I also like @BozeWolf's suggestion
| below about charging for new accounts.
|
| You could even do a combo. Like $25 sign up. Free with
| referral.
| pimlottc wrote:
| Of course, it should also be noted that these will create
| burdens for legitimate users as well, in some cases
| disproportionately (e.g. new developers will have a harder time
| getting referrals).
| dlor wrote:
| I know folks hate the centralization of identity management to
| the big identity providers, but as AI gets better and better at
| defeating captcha it's going to get harder and harder for the
| small, independent ones to operate reliably and securely.
| adhesive_wombat wrote:
| "Never use your real name on that internet thing" will soon be
| a quaint throwback.
| pixl97 wrote:
| We're moving closer to "when you post on the internet, it is
| signed and big brother knows you did it. Watch your words"
| tzhenghao wrote:
| Tragedy of the commons - only need a few bad actors to ruin it
| all for us. Almost all distributors face this problem, from
| Docker Hub to PyPI. This also reminded me of official Postgres
| Docker image running a cryptominer in the background [1]
|
| [1] - https://github.com/docker-library/postgres/issues/770
| brasetvik wrote:
| Reading that thread it doesn't seem like the official image
| shipped with any cryptominer at any point, and that it's more
| likely that the container got compromised in other ways. (A
| compromised [superuser connection to Postgres can execute shell
| code](https://medium.com/r3d-buck3t/command-execution-with-
| postgre...), so that seems more likely than the image shipping
| with a miner)
| boomanaiden154 wrote:
| It doesn't seem like the linked Github issue really backs up
| the claim that malware was getting shipped in the official
| image? The OP kept claiming that (even titling it
| `[Confirmed]`), but only one other person was able to
| corroborate the claim and their image hashes didn't match any
| of the hosted ones.
| nonethewiser wrote:
| That is a very interesting read. The maintainers seem more sane
| than Antender. Im even sympathetic to many of his points but he
| cant be sure a maintainer put a cryptominer in the image.
| Shouldnt be so fast to point fingers.
|
| Are there any aggregators of interesting github issues? Links
| with a bit of context about them make for some fascinating
| reads.
| BozeWolf wrote:
| I wonder if Apple's trick would work for python packages. Pay a
| few (5? 10? 20?) bucks to become a Pypi developer/sponsor, it
| would also pay pypi's operational bills. It raises the bar for
| malicious actors.
|
| Additionally, if pypi provides keys to developers, pypi can also
| revoke certificates for developers making malicious packages.
|
| It would need a system which checks package signatures on startup
| of a python app, or maybe there is some other way to do that. Pip
| --check or some thing which then runs in pipelines, specifically
| meant to check for malicious packages each day.
|
| To decrease the barrier of entry on pypi, students could identify
| with their student number. Or pypi could work with a system where
| you have trusted users and packages and untrusted users. A bit
| like the blue checkmark, but without the negative connotation.
| CameronNemo wrote:
| Universities could host gitlab instances with pypi registries
| built-in.
| miohtama wrote:
| You can always have a trusted community member to waive the
| payment requirement, so anyone who demostrates genuine effort
| can have it for free.
| BozeWolf wrote:
| This. Also enterprises using specific (still untrusted)
| packages could pay it for the developer. There must be a way
| to do this. But in true spirit of python the system should be
| as open as possible.
| woodruffw wrote:
| FD: I've done some work on PyPI, but I am not an admin and
| everything below is an independent opinion/understanding.
|
| PyPI's operational costs are, to my understanding, mostly
| covered: hosting is graciously provided by a sponsor, and the
| PSF currently funds roles for its develop, administration, and
| security. More funding is always good and I believe the PyPI
| admins are looking to enable payments through the newly
| released "Organizations" feature[1].
|
| > Additionally, if pypi provides keys to developers, pypi can
| also revoke certificates for developers making malicious
| packages.
|
| There are currently plans in progress to allow PyPI users to
| upload Sigstore[2] signatures for packages.
|
| That won't directly address the spam issue, however --
| signatures will be opt-in (by necessity, due to the size of the
| packaging ecosystem), and no codesigning scheme can prevent a
| spammer from simply assuming a new identity (especially when
| new identities are "free," as they normally are.)
|
| Separately, revocation itself is a nasty problem for packaging
| ecosystems to deal with: ecosystems with trillions of dollars
| of value behind them (like the Web PKI) struggle with it, so
| it's not immediately clear that it would be anything other than
| an additional operational burden.
|
| Similarly for reputational systems: they're difficult to
| operationalize without additional maintainer burden. That's not
| to say that they're necessarily bad or impractical for PyPI's
| purposes; only that I'm not aware of a _successful_ use of them
| in an open source packaging ecosystem. Compare, for example,
| PGP's WoT failures.
|
| [1]: https://blog.pypi.org/posts/2023-04-23-introducing-pypi-
| orga...
|
| [2]: https://www.sigstore.dev/
| benatkin wrote:
| I hope they get a handle on this and don't do anything else to
| alienate data portability folks like making Microsoft the only
| "Trusted Publisher".
|
| https://news.ycombinator.com/item?id=35646436
| ewdurbin wrote:
| there are no plans to limit trusted publishers. in fact there
| is another in the works:
| https://github.com/pypi/warehouse/issues/13551
| kccqzy wrote:
| A massive amount of people signing up with malicious intent (the
| Sybil attack) is a thing afflicting every single online service
| with a signup. I don't blame PyPI, but I think it's genuinely a
| hard problem to solve. Big Tech often combats this by running a
| bunch of heuristics and suspending accounts they detect to be
| bad, but of course we know how easy it is for even tiny false
| positives to blow up. I think we might come to the end of the era
| of free online accounts; only those accounts requiring a method
| of payment will continue to be viable.
___________________________________________________________________
(page generated 2023-05-20 23:00 UTC)