On Sep 21, 2013, at 10:42 AM, Nick Coghlan <ncoghlan@gmail.com> wrote:

I work in the same office as some of the folks that are working on the victi.ms vulnerability database for Java projects, and they recently asked me for advice about how to add Python support (they've also been discussing the addition of Ruby support with some of the rubygems.org devs).

So, rather than doing anything purely Python specific, I suspect we're more likely to focus on collaborating effectively with victi.ms rather than duplicating their work.

Near term, major new features aren't likely to be added to the current PyPI code base - the current PyPI development efforts are mostly focused on migrating to a new architecture where the data integrity constraints are strictly enforced at the database layer.

Cheers,
Nick.

_______________________________________________
Distutils-SIG maillist  -  Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig

Just to throw my 2 cents in here as a maintainer of both pip and PyPI.

Something like this is definitely something I want to have. I'd need to spend some time thinking more about it because It's been on my "future" stack. It's likely that integrating with a trusted third party service is a viable (and good!) option since historically PyPI itself hasn't been in the business of vetting what people upload to it. 

Any changes to PyPI would require the projects themselves to flag a security issue which won't always happen. A third party project allows a neutral party to handle this.

Also as Nick said PyPI itself is mostly in a holding pattern while a 2.0 is being phased in, new features *are* possible but they are all weighed against the amount of effort it will take (x2).

-----------------
Donald Stufft
PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA