[Catalog-sig] Deprecate External Links

[Aaron Meurer]

On Wed, Feb 27, 2013 at 6:24 PM, Donald Stufft <donald.stufft at gmail.com> wrote:
> On Wednesday, February 27, 2013 at 8:13 PM, PJ Eby wrote:
>
> On Wed, Feb 27, 2013 at 7:36 PM, Donald Stufft <donald.stufft at gmail.com>
> wrote:
>
> This seems a bit complicated, people in general don't even know
> the external link spidering exists, much less understand the intricacies
> of what types of links get spidered when. A simple "After X date no new
> urls will be added and after Y date all existing urls will be removed"
> removes ambiguity from the process. Having "this kind of link will get
> removed Y
> and that matters in Z conditions" leads to a lot of confusion about
> what does and doesn't work.
>
>
> AFAICT, that's an argument in *favor* of phased removals, not against.
> (Also, you have the order backwards from my proposal, which is to
> *first* remove broken old junk in two phases. This is actually *less*
> problematic than doing it for new releases first. And of course the
> simplest thing of all would be to make no change at all.)
>
> The phased removals are a problem when people won't understand
> the differentiating factors between the different phases.
>
>
> Anyway, let's try to be a little bit less like the politicians who,
> upon being told that "Something must be done!", turn around and pick
> any arbitrary value of "something", and do that, so as to be seen to
> be "doing something".
>
> But that is *exactly* what is happening now: people are proposing to
> create worse problems down the line by insisting on doing something
> "right now" (although never is often better, per the Zen of Python)
> without considering the consequences that will happen six months or so
> from now... when the users and toolmakers move the external links
> someplace else, that will have even *less* visibility,
> maintainability, and trust than they have now.
>
> This is not something I've just cooked up, It's been thought about since
> I stood up Crate a year ago, infact there is a /simple/ index on Crate
> that flat out removes external links (as well as all the breakage that
> occurs).
>
> I'm well aware of the implications here. dependency_links cannot be
> controlled
> via PyPI (and infact require a download to even trigger them if they are in
> setup.py) so that problem is outside of the realm of PyPI. Like I said I've
> already opened issues with pip/buildout about this, and I have every
> intention of seeing them through till completion.

Can you give the links to the issues in their issue trackers, for
those of us who want to follow the progress of this more closely?

Aaron Meurer

> PyPI is one part
> of the overall "remove automatic trolling of links from the index" plan.
>
>
> This won't make your problems better, it will actually make them
> *worse*, for the sake of making what is essentially a political
> statement about how seriously the Python community values security.
> (This is especially the case because getting rid of the links won't
> actually get you to a secure system. The *actual* solution is code
> signing... which there is already a PEP for. Get the code signing
> done right, and the external links will be irrelevant.)
>
> Code signing only solves some problems, and this isn't just about security,
> (although it does play a major part) read my previous emails. Furthermore
> code signing is a larger change *and* it's a lot more difficult to get old
> releases to go back and sign their releases. This improves the overall
> security of these old releases even if we are unable to get them signed.
>
>
> Now, I am not saying that something doesn't need to be done, but it
> needs to be considered more carefully than just, "First thing we do,
> let's kill all the links!" A phase-out will not lose anything that
> isn't already lost. (A parallel from Mercurial, when they added SSL
> cert verification: the warnings don't mean things are more insecure
> now, you're just getting informed now of how insecure they *already
> always were*.)
>
>