4 ms·

Thanks for your work! Reading the article, seems like the main debate is on whether this should be included in pip. Fwiw, as a user experience, including it see

Thanks for your work! Reading the article, seems like the main debate is on whether this should be included in pip. Fwiw, as a user experience, including it seems best. I think the experience npm (tries to) provide is a fine goal. However, whether it's a priority for pip and burdening maintainers is another matter. In any case, I'm more concerned with not repeating npm audit's mistakes. Abramov's blog post linked in the article [1] popped to my mind right away. Can you say any more about how pip-audit won't "cry wolf"? Especially since Python doesn't have great packaging standardization around tools, dev-dependencies, build dependencies, pip-tools vs pipenv vs poetry, etc. [1] https://overreacted.io/npm-audit-broken-by-design/ https://overreacted.io/npm-audit-broken-by-design/

woodruffw 4y ago
Sorry for the late response! Yes, this is a great point: we absolutely do not want either the current instantiation of pip-audit or any potential integration to cause security fatigue. Our proposed integration plan was made with this anti-goal in mind: audits will never be “automatic” the way they are in npm, meaning that users will not be suddenly put on the spot to make security decisions about their dependencies. Instead, auditing will always be an intentional action: users will have to explicitly run `pip audit` to receive notices, which they can address synchronously. Separately, on the data side: the JS ecosystem suffers from a deluge of low-value vulnerabilities (things like ReDoS weaknesses), which in turn produce more fatigue. The Python ecosystem avoids those kinds of vulnerabilities mostly incidentally, since Python is not (generally) run on the client side of the browser in the way that JS is. But more formally, our hope is that the community vulnerability database will help us balance fatigue concerns with “completeness” and expose sufficient metadata to allow users to make policy-style decisions about which potential vulnerabilities matter to them.
- nighthawk454 4y ago
  Thanks! I’m not feeling as strongly about needing it to be explicit-run only. Realistically, I’m gonna set up dependabot or something anyway. I actually like that part of npm audit - when I’m doing “package management things” it’s convenient to get those alerts. To me, the problem of noise is wholly separate to when/how I run it. Solving noise by making it run less frequently is a bit of a “you’re holding it wrong”. But I see your point that the nature of Python and hopefully the community database are the real solutions. I did install and try pip-audit though and it had very very few notices and none spurious! So already I like it better than npm audit :)

woodruffw 4y ago

Sorry for the late response! Yes, this is a great point: we absolutely do not want either the current instantiation of pip-audit or any potential integration to cause security fatigue. Our proposed integration plan was made with this anti-goal in mind: audits will never be “automatic” the way they are in npm, meaning that users will not be suddenly put on the spot to make security decisions about their dependencies. Instead, auditing will always be an intentional action: users will have to explicitly run `pip audit` to receive notices, which they can address synchronously. Separately, on the data side: the JS ecosystem suffers from a deluge of low-value vulnerabilities (things like ReDoS weaknesses), which in turn produce more fatigue. The Python ecosystem avoids those kinds of vulnerabilities mostly incidentally, since Python is not (generally) run on the client side of the browser in the way that JS is. But more formally, our hope is that the community vulnerability database will help us balance fatigue concerns with “completeness” and expose sufficient metadata to allow users to make policy-style decisions about which potential vulnerabilities matter to them.

nighthawk454 4y ago
Thanks! I’m not feeling as strongly about needing it to be explicit-run only. Realistically, I’m gonna set up dependabot or something anyway. I actually like that part of npm audit - when I’m doing “package management things” it’s convenient to get those alerts. To me, the problem of noise is wholly separate to when/how I run it. Solving noise by making it run less frequently is a bit of a “you’re holding it wrong”. But I see your point that the nature of Python and hopefully the community database are the real solutions. I did install and try pip-audit though and it had very very few notices and none spurious! So already I like it better than npm audit :)