4 ms·

There’s really two separate concepts here: review and the standard library. Why not separate concerns and have a review process that isn’t coupled to the standa

There’s really two separate concepts here: review and the standard library. Why not separate concerns and have a review process that isn’t coupled to the standard library? There’s no reason why any PyPI package can’t have meaningful reviews published. The question that you’re ultimately seeking the answer to is “what code has been reviewed and which reviewers do I trust?” - lots of ways to solve that.

anoncake 7y ago
One reason for this proposal is to save manpower. Separating concerns doesn't help with that.
- kgwgk 7y ago
  It does save manpower for Python maintainers if reviewing non-core libraries becomes someone else’s problem.
  - anoncake 7y ago
    Either the reviewer is trusted and might as well review the libraries as part of the standard library or they are not trusted and reviews by them are useless.
- afiori 7y ago
  But keeping them together does not need a standard library, each python distribution could have a set of blessed packages, those packages could be "unblessed" without breaking applications using them
- lmm 7y ago
  If the two tasks require different skillsets (and they do) then separating them could easily mean more people are able and willing to help with one or the other.
Kalium 7y ago
> There’s no reason why any PyPI package can’t have meaningful reviews published You are completely correct. There's no reason at all why any random PyPI package can't have meaningful reviews published. I would go so far as to say that this is true without any changes to the standard library or current processes at all. With that in mind, I'm thinking about all the various packages my colleages use. I don't think I've seen published reviews for an appreciable fraction of them in any language. This suggests that perhaps enabling reviews might not be the hard problem to solve here. This thought process also hilights to me that the major advantage of a stdlib is that you have a higher degree of assurance that its contents have seen meaningful review by multiple sets of eyes. It's not just the potential for review that matters, it's the degree of assurance.
alexchamberlain 7y ago
I wonder if something like Arch Linux's main repository vs AUR would work?
zwp 7y ago
> “what code has been reviewed and which reviewers do I trust?” Thank you for putting this so succinctly. There are other supply-chain problems in decentralizing control of the modules though: Modules might only have a few people or one person responsible for them. Consequently suspect commits by a malfeasant or compromised (hacked) team member might not be noticed. Maybe this is a variant of the old saw "with enough eyes all bugs are shallow" but my gut feeling is that commits to Python core will get more inspection than those to a small 3rd party module. Today, modules get some review for free, just by being part of stdlib. Even if I know and trust @jdoe I have less assurances that they didn't get phished and their repo tweaked. Also trusted team members/organizations may change over time. The browser extensions world is the poster child for this, where we've seen not only similarly-named malicious extensions posted to stores but also once-legitimate extensions quietly purchased and subsequently subverted by bad actors. This is one example (adware: could've been much worse): https://www.bleepingcomputer.com/news/security/-particle-chrome-extension-sold-to-new-dev-who-immediately-turns-it-into-adware/ https://www.bleepingcomputer.com/news/security/-particle-chr... I like the idea of a review process but I have a hard time imagining a crowd-sourced system that wouldn't get gamed. We have a "dissolution of responsibility" problem: millions of companies rely on these components but have no explicit responsibility of care. Perhaps that needs to change, somehow.
- pas 7y ago
  Companies (and anyone interested) could simply pool funds together and use that to ask already trusted and respected auditors to do reviews. And anyone who pays into the fund should be able to vote on what package to review. (And there should be a weighted lottery, so eventually small contributors' wishes have a chance to get fulfilled.) For good measure anyone can put this on the blockchain, make a flattr/patreon thing out of this. (Somehow use github sponsoring...) Who knows.

anoncake 7y ago

One reason for this proposal is to save manpower. Separating concerns doesn't help with that.

kgwgk 7y ago
It does save manpower for Python maintainers if reviewing non-core libraries becomes someone else’s problem.
- anoncake 7y ago
  Either the reviewer is trusted and might as well review the libraries as part of the standard library or they are not trusted and reviews by them are useless.
afiori 7y ago
But keeping them together does not need a standard library, each python distribution could have a set of blessed packages, those packages could be "unblessed" without breaking applications using them
lmm 7y ago
If the two tasks require different skillsets (and they do) then separating them could easily mean more people are able and willing to help with one or the other.

Kalium 7y ago

> There’s no reason why any PyPI package can’t have meaningful reviews published You are completely correct. There's no reason at all why any random PyPI package can't have meaningful reviews published. I would go so far as to say that this is true without any changes to the standard library or current processes at all. With that in mind, I'm thinking about all the various packages my colleages use. I don't think I've seen published reviews for an appreciable fraction of them in any language. This suggests that perhaps enabling reviews might not be the hard problem to solve here. This thought process also hilights to me that the major advantage of a stdlib is that you have a higher degree of assurance that its contents have seen meaningful review by multiple sets of eyes. It's not just the potential for review that matters, it's the degree of assurance.

alexchamberlain 7y ago

I wonder if something like Arch Linux's main repository vs AUR would work?

zwp 7y ago

> “what code has been reviewed and which reviewers do I trust?” Thank you for putting this so succinctly. There are other supply-chain problems in decentralizing control of the modules though: Modules might only have a few people or one person responsible for them. Consequently suspect commits by a malfeasant or compromised (hacked) team member might not be noticed. Maybe this is a variant of the old saw "with enough eyes all bugs are shallow" but my gut feeling is that commits to Python core will get more inspection than those to a small 3rd party module. Today, modules get some review for free, just by being part of stdlib. Even if I know and trust @jdoe I have less assurances that they didn't get phished and their repo tweaked. Also trusted team members/organizations may change over time. The browser extensions world is the poster child for this, where we've seen not only similarly-named malicious extensions posted to stores but also once-legitimate extensions quietly purchased and subsequently subverted by bad actors. This is one example (adware: could've been much worse): https://www.bleepingcomputer.com/news/security/-particle-chrome-extension-sold-to-new-dev-who-immediately-turns-it-into-adware/ https://www.bleepingcomputer.com/news/security/-particle-chr... I like the idea of a review process but I have a hard time imagining a crowd-sourced system that wouldn't get gamed. We have a "dissolution of responsibility" problem: millions of companies rely on these components but have no explicit responsibility of care. Perhaps that needs to change, somehow.

pas 7y ago
Companies (and anyone interested) could simply pool funds together and use that to ask already trusted and respected auditors to do reviews. And anyone who pays into the fund should be able to vote on what package to review. (And there should be a weighted lottery, so eventually small contributors' wishes have a chance to get fulfilled.) For good measure anyone can put this on the blockchain, make a flattr/patreon thing out of this. (Somehow use github sponsoring...) Who knows.