<div dir="ltr">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.<div><br></div><div>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.<br><div><div><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Jul 22, 2016 at 12:57 PM, Randy Syring <span dir="ltr"><<a href="mailto:randy@thesyrings.us" target="_blank">randy@thesyrings.us</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">
  
    
  
  <div bgcolor="#FFFFFF" text="#000000"><span>
    <br>
    <div>On 07/22/2016 12:39 PM, Donald Stufft
      wrote:<br>
    </div>
    <blockquote type="cite">
      <pre></pre>
      <blockquote type="cite">
        <pre>On Jul 22, 2016, at 11:47 AM, Chris Barker - NOAA Federal <a href="mailto:chris.barker@noaa.gov" target="_blank"><chris.barker@noaa.gov></a> wrote:


If the core devs think it's fine and dandy like it is, we can all stop
talking about it.
</pre>
      </blockquote>
      <pre>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.
</pre>
    </blockquote></span>
    Is there a place where the currently proposed solutions are briefly
    outlined?<br>
    <br>
    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:<br>
    <br>
    default/flask<br>
    legacy/flask <br>
    (you get the point, probably need a better name)<br>
    <br>
    unless the user has registered on pypi for an organization and
    publishes the package under that org:<br>
    <br>
    pallets/flask<br>
    <br>
    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.  <br>
    <br>
    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.<br>
    <br>
    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."<br>
    <br>
    Has this been proposed before?  Any interest?<br>
    <div><br>
      <b>Randy Syring</b><br>
      <small>Husband | Father | Redeemed Sinner</small><br>
      <br>
      <i><small>"For what does it profit a man to gain the whole world<br>
          and forfeit his soul?" (Mark 8:36 ESV)</small></i>
      <br>
    </div>
    <br>
  </div>

<br>_______________________________________________<br>
Distutils-SIG maillist  -  <a href="mailto:Distutils-SIG@python.org" target="_blank">Distutils-SIG@python.org</a><br>
<a href="https://mail.python.org/mailman/listinfo/distutils-sig" rel="noreferrer" target="_blank">https://mail.python.org/mailman/listinfo/distutils-sig</a><br>
<br></blockquote></div><br></div></div></div></div></div>