[Distutils] Outdated packages on pypi

[Nick Timkovich]

A more conservative approach might be to flag high-risk, typo-prone package
names as requiring moderator approval to register. Some combination of
looking at common 404s (or whatever happens when a client asks for a
non-existent package), some string metrics (Levenshtein, Jaro, whatever) to
an existing package, etc. could be used. Light moderation should be able to
tell that someone who wants to register "requsets" should maybe be
challenged as to why.

Someone that wants to typo-attack would need to go after many more
low-value names. That said, is there some sort of rate-limiter in place to
prevent someone from registering hundreds of names in a short span?
Probably easy to defeat with multiple accounts though? In any event,
figuring out how to best attack PyPI/pip users is the best way to improve
security.

On Fri, Jul 22, 2016 at 12:57 PM, Randy Syring <randy at thesyrings.us> wrote:

>
> On 07/22/2016 12:39 PM, Donald Stufft wrote:
>
> On Jul 22, 2016, at 11:47 AM, Chris Barker - NOAA Federal <chris.barker at noaa.gov> <chris.barker at noaa.gov> wrote:
>
>
> If the core devs think it's fine and dandy like it is, we can all stop
> talking about it.
>
> I think they’re certainly a problem. The current solutions that have been
> proposed have their own problems of course, and problems enough that I
> don’t feel comfortable implementing them. Personally I don’t currently have
> the time to work on a better solution but if someone did that’d be fine
> with me.
>
> I would mention though that it’s possible there *is* no solution to this
> problem that doesn’t bring with it it’s own problems that are worse then
> the problem at hand. I’m not saying that’s the case, but just mentioning
> that it may be so.
>
> Is there a place where the currently proposed solutions are briefly
> outlined?
>
> One solution that seems apparent to me is to move to an org/package
> hierarchy like what GitHub has.  By default, packages get published under a
> default namespace:
>
> default/flask
> legacy/flask
> (you get the point, probably need a better name)
>
> unless the user has registered on pypi for an organization and publishes
> the package under that org:
>
> pallets/flask
>
> You would still have contention at the org level, but my guess is this
> contention would be much less significant than the current contention that
> is faced with only having a single-level namespace for package names.  You
> could further improve this by having org creation requests either A)
> approved to prevent name squatting or B) have an appeal process for org
> name squatting that is blatant (e.g. I register the "google" or "pypa" org)
> and/or C) expire orgs that are no longer maintained.
>
> The details of both A & B & C would be tricky to get right, but the rules
> would at least be decided on from the beginning, so people know what the
> conditions are.  If they don't like those conditions, then they don't get
> an org, and the situation they are in with name contention is exactly the
> same as it is now.  All legacy packages operate under the current ruleset.
> All orgs and their packages operate under the new ruleset.  Hopefully
> avoiding complaints of "you changed the game on us."  You could also
> operate the org registration idea under "beta" conditions for first couple
> years to work out kinks in the process and warn people up-front that the
> rules could change during that time.
>
> By mapping all current packages under some "legacy" namespace, there
> should be room for backwards compatibility.  So, if my projects require
> "flask" either pip or Warehouse knows to return "legacy/flask."
>
> Has this been proposed before?  Any interest?
>
> *Randy Syring*
> Husband | Father | Redeemed Sinner
>
>
> *"For what does it profit a man to gain the whole world and forfeit his
> soul?" (Mark 8:36 ESV)*
>
>
> _______________________________________________
> Distutils-SIG maillist  -  Distutils-SIG at python.org
> https://mail.python.org/mailman/listinfo/distutils-sig
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20160722/56e26f7a/attachment.html>