On 20 July 2016 at 14:13, Wes Turner <wes.tur...@gmail.com> wrote: >> - near-zero additional maintenance overhead for tooling maintainers >> that don't care about the semantic web > > Is it of value to link CVE reports with the package metadata?
On PyPI, the main value would be in publisher notification (i.e. if folks maintaining projects on PyPI aren't tracking CVE reports directly, it would be nice if they could opt in to having PyPI do it for them rather than having to learn how to navigate the CVE ecosystem themselves - "Maintainers are actively monitoring CVE notifications" would then become a piece of metadata PyPI could potentially publish to help distinguish people's personal side projects from projects with funded developers supporting them). Similarly, given suitable investment in Warehouse development, PyPI could be enhanced to provide a front-end to the experimental Distributed Weakness Filing system, where folks can request assignment of CVE numbers in a more automated way than the traditional process. However, for clients, the problem with relying on PyPI for CVE notifications is that what you actually want as a developer is a situation where your security notifications are independent of the particular ecosystem providing the components, and also where a compromise of your connection to the software publication platform doesn't inhibit your ability to be alerted to security concerns. While there *are* ecosystem specific services already operating in that domain (e.g. requires.io for Python), the cross-language ones like VersionEye.com and dependencyci.com are more valuable when you're running complex infrastructure, since they abstract away the ecosystem-specific differences. While the previously mentioned libraries.io is the release notification component for dependencyci.com, release-monitoring.org is a service written in Python by the Fedora Infrastructure team to provide upstream release notifications to Linux distributions that's been around for a while longer, hence why that tends to be my own main point of interest. Cheers, Nick. P.S. For anyone that isn't aware, understanding and helping to manage the sustainability of Red Hat's software supply chain makes up a respectable portion of my day job. In the Python ecosystem, that just happens to include pointing out things that volunteers probably shouldn't invest their own time in implementing, since they're good candidates for funded commercial development ;) -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia _______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
