<p dir="ltr">Richard's in transit at the moment and I'm about to be, but this sounds worth doing to me.</p>
<p dir="ltr">I say send the pull request :)</p>
<p dir="ltr">Cheers,<br>
Nick.</p>
<div class="gmail_quote">On 12 Mar 2013 09:42, "Donald Stufft" <<a href="mailto:donald@stufft.io">donald@stufft.io</a>> wrote:<br type="attribution"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
On Mar 11, 2013, at 7:04 PM, PJ Eby <<a href="mailto:pje@telecommunity.com">pje@telecommunity.com</a>> wrote:<br>
<br>
> Just a thought, but...<br>
><br>
> If 90% of PyPI projects do not have any external files to download,<br>
> then, wouldn't it make sense to:<br>
<br>
To be accurate it's 90% don't have any files/release available *only* externally. Most have external  files to download because it's very rare that a project doesn't include an home_page or a download_url, especially since distutils complains if you don't.<br>

<br>
><br>
> 1. Add a project-level option to enable or disable the adding of the<br>
> rel="" attribute to /simple links (but not affecting the links in any<br>
> other way)<br>
> 2. Default it to disabled for new projects, and<br>
> 3. Set it to disabled *now* for the 90% of projects that *don't have<br>
> external files*?<br>
<br>
+1 except 1. should be to remove the links entirely from the /simple/<br>
index, not to just remove the rel attribute.<br>
<br>
><br>
> If the arguments about banning external links are as valid and<br>
> important as some people claim, wouldn't it make sense to do this part<br>
> *now*, without first requiring a commitment to force the switch to a<br>
> disabled state in the future?<br>
><br>
> Immediately, 90% of the problem goes away - no random spidering of<br>
> stuff that doesn't contain a link now, but which could be taken over<br>
> by a malicious party in the future, and 90% fewer sites having to be<br>
> up in order for you to build something from PyPI.<br>
><br>
> Seems like a serious win to me -- and one that might not even need a PEP.<br>
<br>
Absolutely, and similar to something I asked Richard at the start of this, I'm waiting on an OK from someone with authority that they'd merge such a change and I'll have a PR out for it asap after that.<br>
<br>
><br>
> Next steps after this would be providing tools to help people move<br>
> their files and links, promoting that people switch it off if they no<br>
> longer support the offsite links, educating about security concerns,<br>
> etc.<br>
><br>
> I really don't understand why the 90% solution isn't *already* the<br>
> consensus position, since it doesn't preclude follow-on efforts<br>
> towards reducing the 10% towards 0%.<br>
><br>
> And if the problem is so important, why must we keep 90% of the<br>
> problems in place, just so we can keep arguing about censoring the<br>
> 10%?  That doesn't make sense to me.<br>
><br>
> To me, if somebody's injured, the first thing you do is clean and<br>
> close the wound, not argue about whether it's a complete solution and<br>
> what might happen days or weeks later.<br>
<br>
Like I said above, I'm just waiting on an ok that this has a chance of landing before bothering to implement it.<br>
<br>
><br>
> Just a thought.<br>
> _______________________________________________<br>
> Catalog-SIG mailing list<br>
> <a href="mailto:Catalog-SIG@python.org">Catalog-SIG@python.org</a><br>
> <a href="http://mail.python.org/mailman/listinfo/catalog-sig" target="_blank">http://mail.python.org/mailman/listinfo/catalog-sig</a><br>
<br>
<br>
-----------------<br>
Donald Stufft<br>
PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA<br>
<br>
<br>_______________________________________________<br>
Catalog-SIG mailing list<br>
<a href="mailto:Catalog-SIG@python.org">Catalog-SIG@python.org</a><br>
<a href="http://mail.python.org/mailman/listinfo/catalog-sig" target="_blank">http://mail.python.org/mailman/listinfo/catalog-sig</a><br>
<br></blockquote></div>