<p dir="ltr"><br>
On 22 Sep 2013 01:20, "Dariusz Suchojad" <<a href="mailto:dsuch@zato.io">dsuch@zato.io</a>> wrote:<br>
><br>
> On 09/21/2013 04:51 PM, Donald Stufft wrote:<br>
><br>
> > Any changes to PyPI would require the projects themselves to flag a<br>
> > security issue which won't always happen. A third party project allows a<br>
> > neutral party to handle this.<br>
><br>
> One thing I don't fully get is how <a href="http://victi.ms">victi.ms</a> - or any third party -<br>
> collect information regarding the vulnerabilities?<br>
><br>
> I understand there would be two sources of information?<br>
><br>
> - public vulnerability databases<br>
> - data submitted by package maintainers themselves (this would have to<br>
> be routed to a third party somehow)</p>
<p dir="ltr"><a href="http://victi.ms">victi.ms</a> is still in the process of launching - they want to have at least Java, Python and Ruby support before making a big push to promote it as a resource.</p>
<p dir="ltr">I believe the initial intent is for <a href="http://victi.ms">victi.ms</a> to focus on mapping CVE numbers to upstream packages, and then have optional plugins to check Maven builds, Ruby gem dependencies and Python virtual environments for known vulnerable versions.</p>

<p dir="ltr">For PyPI integration, I would expect to initially see us as just a consumer of the data, displaying CVE information on PyPI when available, and likely republishing it through the PyPI APIs.</p>
<p dir="ltr">Even that would be a big step forward from where we are now :)</p>
<p dir="ltr">Cheers,<br>
Nick.</p>
<p dir="ltr">> > Also as Nick said PyPI itself is mostly in a holding pattern while a 2.0<br>
> > is being phased in, new features *are* possible but they are all weighed<br>
> > against the amount of effort it will take (x2).<br>
><br>
> Sure, I understand it now.<br>
><br>
> cheers,<br>
><br>
> --<br>
> Dariusz Suchojad<br>
><br>
> <a href="https://zato.io">https://zato.io</a><br>
> ESB, SOA and cloud integrations in Python<br>
</p>