9 ms·

The argument the author makes seems really nonsensical. It really comes off as "i would like to have my cake and eat it too". It's true it's not the fault of

The argument the author makes seems really nonsensical. It really comes off as "i would like to have my cake and eat it too". It's true it's not the fault of the author that a thing became popular. So what? If you don't want the responsibilities of being popular through a given distribution mechanism, then great, don't use that distribution mechanism. Nobody is forcing you. That will cause you to have no responsibility. It will likely cause your adoption to be lower, but you just argued that it isn't your fault adoption is so high, so presumably you don't care. Otherwise you are arguing that you owe nobody anything, because it's not your fault, but the distribution mechanisms owe you something - free distribution without responsibility! In reality, most people care a lot and want their project to be popular, so making arguments that "it's not the authors fault it is popular" are generally pretty disingenuous. Whether that is the case here, who knows, but it is pretty hard to be sympathetic to an argument that plays both sides, and claims you owe nobody anything while the distribution mechanisms owe you something.

brabel 4y ago
This kind of reply is frustrating. Someone wrote a nice article explaining how it may not be desirable for package indexes to force the authors of packages to put on even more work to get their free work published, work that they didn't have to do before... and the best answer you can come up with "that's nonsensical"? Here's what is nonsensical: to call the author's argument "i would like to have my cake and eat it too" because the author does not ask to eat any cake... they just ask that package authors should not be burdened with even more work the more their creation becomes popular, and that the burden should be on users who care about it... to call this argument nonsensical is offensive to the author and to those who read the argument and actually understand it.
- staticassertion 4y ago
  > they just ask that package authors should not be burdened with even more work the more their creation becomes popular, and that the burden should be on users who care about it... Yes, the "having the cake" would be the ability to publish code to pypi and the "eating it too" would be the abdication of responsibility to abide pypi policy.
- bastawhiz 4y ago
  > they just ask that package authors should not be burdened with even more work the more their creation becomes popular, and that the burden should be on users who care about it PyPi is free and not the only way to distribute your software. You're welcome to self host. PyPi, in order to be successful as a package repository, needs to serve both authors AND users. If you don't want to abide by the new policy? You don't need to use PyPi, and your account is presumably locked. Nothing is taken away from you except your ability to continue to use a free service for free without abiding by their security policies. This is as nonsensical as being upset that PyPi is enforcing minimum password length or requiring HTTPS. They're not making money from this, they're obviously not doing it maliciously. The motive here is to stem a very serious problem with package management (across all of software) in a really mundane, minimal effort way. Specifically when you say "the burden should be on the users who care about it," those users are YOUR users. They turn to your PyPi identity as a source of trust for the packages they download. If there's a new version published under YOUR profile, it's not possible to know whether that package came from you or not unless YOU do more work (reliably publishing about it elsewhere). This problem can't be put on the users of the software because there's no reasonable way for them to actually accomplish what you're describing. To say that the author here should not have any responsibility ignores the core premise of what PyPi does. Frankly, putting the burden on the user would be blocking access to these packages unless the user explicitly opted in with messaging like "Flask is owned by an account which has no 2fa enabled. This could result in a supply chain attack in the future. Are you sure you wish to install it?" I think we can all agree this isn't the right way to solve the problem.
  - ipaddr 4y ago
    A flag would provide choice and unburden everyone.
- lopatin 4y ago
  Personally I am not outraged by the fact that Python’s most popular package authors must go through the “burden” of authenticating their accounts properly.
- deleted 4y ago
  [deleted]
dlor 4y ago
I agree it's nonsense. The argument appears to dodge 2FA itself and the benefits to ecosystem by instead focusing on fairness, which is subjective at best. It's not "fair" that the author has to accept the burden of 2FA, because they created a package that turned out to be critical through no fault of their own. It would seemingly satisfy the author's "fairness" goal if everyone had to use 2FA whether their packages are critical or not. It's also ironically not "fair" that the volunteer maintainers of PyPI are subjected to complaints like this for their hard and valuable work to improve the security of the entire ecosystem, which has become critical infrastructure itself through no fault of their own.
perrygeo 4y ago
> Nobody is forcing you. Well, the author was happily using that distribution mechanism and built a community of users whose production systems are now locked into it. Then they rules changed unilaterally, effectively holding access to that community hostage. They most certainly are forcing the author to do something! Sure the author had a choice to not use PyPi when they initially published a package. But doing so NOW, yanking the project and publishing elsewhere, would directly cause massive amounts of problems that would need to be solved. Who's going to do that labor? The author. There's no reasonable interpretation of this situation that doesn't involve the author being forced to do something.
the_mitsuhiko 4y ago
Author here: > If you don't want the responsibilities of being popular through a given distribution mechanism, then great, don't use that distribution mechanism. The rules in a way are changing with the threshold of "criticality". In a way what you are proposing is suggesting to developers to unpublish if they do not want to deal with the complexity of that. This is exactly what happened yesterday accidentally (https://news.ycombinator.com/item?id=32026624 https://news.ycombinator.com/item?id=32026624). From the responses I have witnessed to that incident I do not believe this a path anyone should take. > claims you owe nobody anything while the distribution mechanisms owe you something The post explicitly states that the distribution mechanism doesn't owe developers anything.
- Tainnor 4y ago
  I think "unpublishing" packages is generally not something that should be done, except in the case of malware and maybe some other cases, and I believe that e.g. NPM already went through an iteration of this issue, which is why they have an explicit policy around it: https://docs.npmjs.com/policies/unpublish https://docs.npmjs.com/policies/unpublish But I would suggest to developers that if their contribution becomes "critical" and they don't want to bear that burden anymore, they should lose the rights to make any further updates, which is, I believe, also the line that PyPI itself takes. The fact that a package got yanked from the registry because of this is an unfortunate combination of a) PyPI allowing it (they shouldn't, and learn from NPM's mistakes), and b) the maintainer being really unreasonable in the face of a perfectly reasonable request.
  - Brian_K_White 4y ago
    There is no reason the index can't do the extra thing they want for their own reasons themselves. There is no valid reason to demand the already-a-volunteer do anything extra to supply something they want for their own reasons. They could collect the source and vet the updates all kinds of other ways than demanding the author jump through hoops for them, for free.
    - staticassertion 4y ago
x86x87 4y ago
Don't agree with your interpretation of what the original author is trying to convey. It's not about the rules of the package distribution channel has. It's about the fact that they have different rules for different levels of popularity. If everyone needed to do 2FA fine. Don't want to do it? Guess you'll distribute your code another way. But... You can use it and we're going to gladly take your free work and host it and in the process benefit from it (look! It's so simple publishing stuff! Use us) until the liability of hosting you becomes greater than the benefit of hosting you. At that point we need to pull out the adult rulebook and teach you how to properly do things. So to me it sounds like the distribution channels want to have their cake and eat it too while passing the work to the developers,ie the people that made the distribution channels successful in the first place.
Brian_K_White 4y ago
The author doesn't want anything. The index wants something for their own reasons, but for some reason considers it reasonable to demand the author do something they want instead of doing the thing they want themselves. The author provides various ideas for how they could get what they want by doing it themselves or by organizing volunteers who choose to work on that. It's like demanding a better man-page than the author supplied, instead of writing one or facilitating someone else who may be willing to work on documentation.
- deleted 4y ago
  [deleted]
- rrdharan 4y ago
  Federated / self-service responsibilities are the only way things like this ever scale. In your example, it makes sense the index wants to push the responsibility out broadly, there’s no way the index can develop the breadth and depth of expertise necessary to write high quality man pages for every package - they’re too busy using their limited resources on maintaining the index (their “vertical”).
  - Brian_K_White 4y ago
    So what? Too bad? No one else's problem? The reasons they want things vetted and attested was never contested. The fact it's a lot of work, is a given. And neither of those things explain why the author has to do it, necessarily. Maybe it's natural, maybe the author of a thing is generally the best positioned to attest and support their own output, but so what? If they find the software valuable enough that it matters that it's verified and certified, and the supplier doesn't feel like doing it, they could do it themselves or arrange for others to to do it or delist the filthy uncertified package or just tag it as not certified. There are all kinds of options besides demanding a volunteer do something they didn't aldeady feel like doing voluntarily. I don't get why everyone confuses the obligations here. Just because pypy wants something, no matter how understandable the reasons, doesn't change the fact that it's pypy who wants it, for their own reasons. The author derives no value from it (not neccessarily, they may choose to value the credit and exposure of their work appearing in the index, but they also may not). Pypy derives value from it, and all of the users derive value from it. The obligation for supplying that extra frosting they want on the cake lies with those who want it.
krab 4y ago
The author presents a perfectly reasonable alternative with argumentation supporting the position. There is nothing in the article about being forced. Personally, I find the described model - especially with trusted "notaries" - much better. It might also help with open source financing.

brabel 4y ago

This kind of reply is frustrating. Someone wrote a nice article explaining how it may not be desirable for package indexes to force the authors of packages to put on even more work to get their free work published, work that they didn't have to do before... and the best answer you can come up with "that's nonsensical"? Here's what is nonsensical: to call the author's argument "i would like to have my cake and eat it too" because the author does not ask to eat any cake... they just ask that package authors should not be burdened with even more work the more their creation becomes popular, and that the burden should be on users who care about it... to call this argument nonsensical is offensive to the author and to those who read the argument and actually understand it.

staticassertion 4y ago
> they just ask that package authors should not be burdened with even more work the more their creation becomes popular, and that the burden should be on users who care about it... Yes, the "having the cake" would be the ability to publish code to pypi and the "eating it too" would be the abdication of responsibility to abide pypi policy.
bastawhiz 4y ago
> they just ask that package authors should not be burdened with even more work the more their creation becomes popular, and that the burden should be on users who care about it PyPi is free and not the only way to distribute your software. You're welcome to self host. PyPi, in order to be successful as a package repository, needs to serve both authors AND users. If you don't want to abide by the new policy? You don't need to use PyPi, and your account is presumably locked. Nothing is taken away from you except your ability to continue to use a free service for free without abiding by their security policies. This is as nonsensical as being upset that PyPi is enforcing minimum password length or requiring HTTPS. They're not making money from this, they're obviously not doing it maliciously. The motive here is to stem a very serious problem with package management (across all of software) in a really mundane, minimal effort way. Specifically when you say "the burden should be on the users who care about it," those users are YOUR users. They turn to your PyPi identity as a source of trust for the packages they download. If there's a new version published under YOUR profile, it's not possible to know whether that package came from you or not unless YOU do more work (reliably publishing about it elsewhere). This problem can't be put on the users of the software because there's no reasonable way for them to actually accomplish what you're describing. To say that the author here should not have any responsibility ignores the core premise of what PyPi does. Frankly, putting the burden on the user would be blocking access to these packages unless the user explicitly opted in with messaging like "Flask is owned by an account which has no 2fa enabled. This could result in a supply chain attack in the future. Are you sure you wish to install it?" I think we can all agree this isn't the right way to solve the problem.
- ipaddr 4y ago
  A flag would provide choice and unburden everyone.
lopatin 4y ago
Personally I am not outraged by the fact that Python’s most popular package authors must go through the “burden” of authenticating their accounts properly.
deleted 4y ago
[deleted]

dlor 4y ago

I agree it's nonsense. The argument appears to dodge 2FA itself and the benefits to ecosystem by instead focusing on fairness, which is subjective at best. It's not "fair" that the author has to accept the burden of 2FA, because they created a package that turned out to be critical through no fault of their own. It would seemingly satisfy the author's "fairness" goal if everyone had to use 2FA whether their packages are critical or not. It's also ironically not "fair" that the volunteer maintainers of PyPI are subjected to complaints like this for their hard and valuable work to improve the security of the entire ecosystem, which has become critical infrastructure itself through no fault of their own.

perrygeo 4y ago

> Nobody is forcing you. Well, the author was happily using that distribution mechanism and built a community of users whose production systems are now locked into it. Then they rules changed unilaterally, effectively holding access to that community hostage. They most certainly are forcing the author to do something! Sure the author had a choice to not use PyPi when they initially published a package. But doing so NOW, yanking the project and publishing elsewhere, would directly cause massive amounts of problems that would need to be solved. Who's going to do that labor? The author. There's no reasonable interpretation of this situation that doesn't involve the author being forced to do something.

the_mitsuhiko 4y ago

Author here: > If you don't want the responsibilities of being popular through a given distribution mechanism, then great, don't use that distribution mechanism. The rules in a way are changing with the threshold of "criticality". In a way what you are proposing is suggesting to developers to unpublish if they do not want to deal with the complexity of that. This is exactly what happened yesterday accidentally (https://news.ycombinator.com/item?id=32026624 https://news.ycombinator.com/item?id=32026624). From the responses I have witnessed to that incident I do not believe this a path anyone should take. > claims you owe nobody anything while the distribution mechanisms owe you something The post explicitly states that the distribution mechanism doesn't owe developers anything.

Tainnor 4y ago
I think "unpublishing" packages is generally not something that should be done, except in the case of malware and maybe some other cases, and I believe that e.g. NPM already went through an iteration of this issue, which is why they have an explicit policy around it: https://docs.npmjs.com/policies/unpublish https://docs.npmjs.com/policies/unpublish But I would suggest to developers that if their contribution becomes "critical" and they don't want to bear that burden anymore, they should lose the rights to make any further updates, which is, I believe, also the line that PyPI itself takes. The fact that a package got yanked from the registry because of this is an unfortunate combination of a) PyPI allowing it (they shouldn't, and learn from NPM's mistakes), and b) the maintainer being really unreasonable in the face of a perfectly reasonable request.
- Brian_K_White 4y ago
  There is no reason the index can't do the extra thing they want for their own reasons themselves. There is no valid reason to demand the already-a-volunteer do anything extra to supply something they want for their own reasons. They could collect the source and vet the updates all kinds of other ways than demanding the author jump through hoops for them, for free.
  - staticassertion 4y ago

x86x87 4y ago

Don't agree with your interpretation of what the original author is trying to convey. It's not about the rules of the package distribution channel has. It's about the fact that they have different rules for different levels of popularity. If everyone needed to do 2FA fine. Don't want to do it? Guess you'll distribute your code another way. But... You can use it and we're going to gladly take your free work and host it and in the process benefit from it (look! It's so simple publishing stuff! Use us) until the liability of hosting you becomes greater than the benefit of hosting you. At that point we need to pull out the adult rulebook and teach you how to properly do things. So to me it sounds like the distribution channels want to have their cake and eat it too while passing the work to the developers,ie the people that made the distribution channels successful in the first place.

Brian_K_White 4y ago

The author doesn't want anything. The index wants something for their own reasons, but for some reason considers it reasonable to demand the author do something they want instead of doing the thing they want themselves. The author provides various ideas for how they could get what they want by doing it themselves or by organizing volunteers who choose to work on that. It's like demanding a better man-page than the author supplied, instead of writing one or facilitating someone else who may be willing to work on documentation.

deleted 4y ago
[deleted]
rrdharan 4y ago
Federated / self-service responsibilities are the only way things like this ever scale. In your example, it makes sense the index wants to push the responsibility out broadly, there’s no way the index can develop the breadth and depth of expertise necessary to write high quality man pages for every package - they’re too busy using their limited resources on maintaining the index (their “vertical”).
- Brian_K_White 4y ago
  So what? Too bad? No one else's problem? The reasons they want things vetted and attested was never contested. The fact it's a lot of work, is a given. And neither of those things explain why the author has to do it, necessarily. Maybe it's natural, maybe the author of a thing is generally the best positioned to attest and support their own output, but so what? If they find the software valuable enough that it matters that it's verified and certified, and the supplier doesn't feel like doing it, they could do it themselves or arrange for others to to do it or delist the filthy uncertified package or just tag it as not certified. There are all kinds of options besides demanding a volunteer do something they didn't aldeady feel like doing voluntarily. I don't get why everyone confuses the obligations here. Just because pypy wants something, no matter how understandable the reasons, doesn't change the fact that it's pypy who wants it, for their own reasons. The author derives no value from it (not neccessarily, they may choose to value the credit and exposure of their work appearing in the index, but they also may not). Pypy derives value from it, and all of the users derive value from it. The obligation for supplying that extra frosting they want on the cake lies with those who want it.

krab 4y ago

The author presents a perfectly reasonable alternative with argumentation supporting the position. There is nothing in the article about being forced. Personally, I find the described model - especially with trusted "notaries" - much better. It might also help with open source financing.