6 ms·

Author here: > If you don't want the responsibilities of being popular through a given distribution mechanism, then great, don't use that distribution mechanis

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
    > 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. At minimum it's completely unproven that that would be practical, whereas 2FA is trivial and has been widely deployed for decades. But if you feel strongly about this feel free to make a formal proposal. There are some nascent projects exploring this area that you could draw inspiration from and I'd certainly welcome tooling in that area.
    - Brian_K_White 4y ago
      What a weird leap. Now not only the author of some software has to jump through someone else's hoops, I a total bystander also has to? It does not require "feel strongly" to observe the invalidity of some argument. Rather, if you feel so strongly that something should be done, like vet that software, you could do it.
      - staticassertion 4y ago
        You don't have to do anything?
- the_mitsuhiko 4y ago
  > 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. That seems worse to me for quite a few cases that go towards actual burden beyond 2FA. That implies the index will take away someone's permission over their creation as a result of too many other people also started using it. There is a reason why I have a "No Warrenty" clause in the licenses of my Open Source work. I have created it for others to enjoy it, but I reserve the rights to not be burdened by my users for the unpaid labor.
  - giaour 4y ago
    > That implies the index will take away someone's permission over their creation as a result of too many other people also started using it. The creation here is the package, not the distribution channel. You can use an alternative Pypi-compatible index (there's one built into Github, and enterprisey ones can be purchased from Azure or AWS) or you can put instructions for a local build & install on your blog. The maintainers of PyPI should be able to enforce some amount of quality control over their creation, after all.
  - Tainnor 4y ago
    No, they simply take away your rights to publish your creation to their index. You can always publish your creation on your website or wherever.
    - jka 4y ago
      > You can always publish your creation on your website or wherever. What you're suggesting wouldn't solve the problem for critical packages, though; the effect would be similar to yesterday's package unpublish issue[1] (all users of the package would have to update their dependency references despite no change in the content of the code). [1] - https://news.ycombinator.com/item?id=32026624 https://news.ycombinator.com/item?id=32026624
      - staticassertion 4y ago
jnovek 4y ago
I think a lot of people are hung up on the fact that 2FA was your example because 2FA is widely regarded as a good idea. My takeaway from your article is: if I create an open source project and it becomes popular, I’ll have a bunch of responsibilities I didn’t necessarily sign up for. Those responsibilities will probably include things that I don’t know how to do or don’t want to do as an IC. I suppose some people are looking for that when they work on open source, but I am personally almost never looking for more responsibility. I have enough already, thank you. I wonder how many more people would contribute to open source projects if they knew they wouldn’t have to worry about project drama or being guilted into taking on more responsibility? I think it’s a very real (and probably measurable) chilling effect. EDIT: to respond to the reply below, I realize that the amount of effort scales with the popularity of the project, but nobody joins the basketball team to warm the bench, you know? Why would I join a system where the definition of success is unpleasant to me?
- dataflow 4y ago
  > EDIT: to respond to the reply below, I realize that the amount of effort scales with the popularity of the project, but nobody joins the basketball team to warm the bench, you know? Why would I join a system where the definition of success is unpleasant to me? I'm pretty sure {your favorite popular basketball player}'s career prospects would not have been impacted by an NBA requirement to "spend 10 seconds sitting on the bench to warm it every day before playing". Doubly so if there was a reasonable argument that it would somehow make the stadium safer for their fans.
- jltsiren 4y ago
  Volunteering is all about taking responsibility. If you contribute regularly to a project with many users, you can't avoid the responsibility. If you only want to express yourself by writing code without the burden of responsibility, you should contribute to something else. One thing I've learned from various volunteer projects and organizations is that good volunteer administrators are rare. Finding good people for the creative parts of the project is not particularly difficult, because creative work is inherently satisfying. Administrators are another story. Many try the job and quit, because they don't enjoy it enough to do it in their free time. Others are not suitable for the role. Some are good and motivated administrators, but they drive other volunteers away by trying to manage them. And then there are the rare ones who can be administrators and enjoy it without ruining the project for everyone else. If you manage to find one, the last thing you want to do is increasing their burden. As far as I understand, PyPI is largely a volunteer project. It works only because some people find running that kind of bureaucracy satisfying. It's their project, and they can run it any way they want. If their burden gets too heavy, they may quit, and then the project may fail. That would probably be a bigger issue than some open source contributors not liking how PyPI is run.
mtrycz2 4y ago
I find it bizarre that they don't ask for 2FA for all contributions. Possibly a historical inheritance? Edit: I now understand that they require a physical device instead of a TOTP app. Yeah, that's the line between reasonable and wtf.
- lopuhin 4y ago
  > they require a physical device instead of a TOTP app. Yeah, that's the line between reasonable and wtf. No, a TOTP app is also allowed.
  - mtrycz2 4y ago
    Well then, that's perfectly reasonable.
    - staticassertion 4y ago
      To tack on, they're actually giving away those tokens for free for those who request one. https://pypi.org/security-key-giveaway https://pypi.org/security-key-giveaway They're being beyond reasonable. This is outright kind.
- Tainnor 4y ago
  > Edit: I now understand that they require a physical device instead of a TOTP app. Yeah, that's the line between reasonable and wtf. They don't.
- btown 4y ago
  2FA, whether TOTP or physical, comes with a per-user support burden for any organization that enforces it, because there must be a human-in-the-loop mechanism to handle "my 2FA devices were all destroyed/stolen, and others depend on me having access to my account." PyPI isn't exempt from this, despite mitigating with multiple 2FA devices, and says as much in the announcement https://pypi.org/security-key-giveaway/ https://pypi.org/security-key-giveaway/ - > Without multiple 2FA options, effect of losing a 2FA method results in the need to fully recover an account, which is burdensome and time-consuming both for maintainers and PyPI administrators. Enabling multiple 2FA methods reduces the potential disruption if one is lost. So there's a huge practical difference to PyPI of enforcing 2FA for all vs. enforcing for <1% of projects. I don't envy their position, and it's a reasonable compromise IMO. That said, it's absurd that PyPI didn't make more clear in the announcement linked above that TOTP apps are allowed. There's literally not an FAQ about the most important FAQ. They very well could have avoided the reaction from OP, and this entire debacle, with more thoughtful messaging.
dataflow 4y ago
Honestly I don't think this is a hill you want to die on. "The greater your influence, the greater your responsibilities" is something society generally agrees is reasonable in most domains, and this is just a manifestation of that principle in the case of OSS and supply-chain integrity. The principle is pretty universal in modern society though. If you see an unreasonable responsibility being placed on you, for sure, complain about that. But if you don't think the responsibility itself (2FA in this case) is unreasonable, and in fact think it should be mandated on everyone, "it's a slippery slope!" and "it's not fair!" are not going to be compelling counterarguments for most people. It goes against what people expect in society.
- frenet 4y ago
  Fundamentally I agree with you. But I also think it easy to get the idea that "no responsibility" is a prevailing view. Or at least that it has to be. There are plenty of people who want to do their best. I would certainly considered the author's software involvement to be part of that. It is just hard to do. And increasing hard not only because of software but society at large (like job and housing markets). So the problem exists regardless of various positions on the issue. Or put another way. If we want open source developers who favor responsibility we have to make it easy for those developers. Otherwise we only end up with people who are fine with throwing things over the wall.
- CJefferson 4y ago
  That doesn't seem to apply to companies -- they make billions from open source and give back little, or nothing, to the majority of the authous and packages whose work they build on. Now that's fine under open source licenses -- but if you want the "free", you also have to take the "no warranty".
- TAForObvReasons 4y ago
  2FA attempts to assert "the person who is publishing the package to the registry is someone that the registry expects" As a user installing from a registry, you are trusting both the publisher AND the distributor. Consider an attack where the distributor is adding malicious code to 1% of installs. The publisher is not involved in the process and (unless code signing is involved) has no influence. But if code signing is involved, why is 2FA even needed? The signatures themselves should be sufficient proof. So 2FA overall is a solution in the lens that the distributor intermediates the relationship. This need not happen. People can chuck tarballs and post signatures, establishing more direct trust compared to the indirect solution.
hanselot 4y ago
Is the whole point of this not to ensure that someone can't use your identity to produce a compromised package? When I download someone else's code its my job to make sure the code I run isn't riddled with spyware. Hence why I design my projects to rely minimally on external dependencies. Why should this burden be placed on the developer and not the user? If I buy a chainsaw and cut my arm off, is this the fault of the chainsaw manufacturer?
- burnished 4y ago
  You do know that bladed machinery is made with more and more safety features right? No one actually thinks "oh fuck em if they lose an arm". It just isn't a good comparison, nor a good solution.
deleted 4y ago
[deleted]
DannyBee 4y ago
"The post explicitly states that the distribution mechanism doesn't owe developers anything." But then goes on to claim otherwise in the rest of it. :) Which means that statement does not actually help your cause.

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
  > 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. At minimum it's completely unproven that that would be practical, whereas 2FA is trivial and has been widely deployed for decades. But if you feel strongly about this feel free to make a formal proposal. There are some nascent projects exploring this area that you could draw inspiration from and I'd certainly welcome tooling in that area.
  - Brian_K_White 4y ago
    What a weird leap. Now not only the author of some software has to jump through someone else's hoops, I a total bystander also has to? It does not require "feel strongly" to observe the invalidity of some argument. Rather, if you feel so strongly that something should be done, like vet that software, you could do it.
    - staticassertion 4y ago
      You don't have to do anything?
the_mitsuhiko 4y ago
> 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. That seems worse to me for quite a few cases that go towards actual burden beyond 2FA. That implies the index will take away someone's permission over their creation as a result of too many other people also started using it. There is a reason why I have a "No Warrenty" clause in the licenses of my Open Source work. I have created it for others to enjoy it, but I reserve the rights to not be burdened by my users for the unpaid labor.
- giaour 4y ago
  > That implies the index will take away someone's permission over their creation as a result of too many other people also started using it. The creation here is the package, not the distribution channel. You can use an alternative Pypi-compatible index (there's one built into Github, and enterprisey ones can be purchased from Azure or AWS) or you can put instructions for a local build & install on your blog. The maintainers of PyPI should be able to enforce some amount of quality control over their creation, after all.
- Tainnor 4y ago
  No, they simply take away your rights to publish your creation to their index. You can always publish your creation on your website or wherever.
  - jka 4y ago
    > You can always publish your creation on your website or wherever. What you're suggesting wouldn't solve the problem for critical packages, though; the effect would be similar to yesterday's package unpublish issue[1] (all users of the package would have to update their dependency references despite no change in the content of the code). [1] - https://news.ycombinator.com/item?id=32026624 https://news.ycombinator.com/item?id=32026624
    - staticassertion 4y ago

jnovek 4y ago

I think a lot of people are hung up on the fact that 2FA was your example because 2FA is widely regarded as a good idea. My takeaway from your article is: if I create an open source project and it becomes popular, I’ll have a bunch of responsibilities I didn’t necessarily sign up for. Those responsibilities will probably include things that I don’t know how to do or don’t want to do as an IC. I suppose some people are looking for that when they work on open source, but I am personally almost never looking for more responsibility. I have enough already, thank you. I wonder how many more people would contribute to open source projects if they knew they wouldn’t have to worry about project drama or being guilted into taking on more responsibility? I think it’s a very real (and probably measurable) chilling effect. EDIT: to respond to the reply below, I realize that the amount of effort scales with the popularity of the project, but nobody joins the basketball team to warm the bench, you know? Why would I join a system where the definition of success is unpleasant to me?

dataflow 4y ago
> EDIT: to respond to the reply below, I realize that the amount of effort scales with the popularity of the project, but nobody joins the basketball team to warm the bench, you know? Why would I join a system where the definition of success is unpleasant to me? I'm pretty sure {your favorite popular basketball player}'s career prospects would not have been impacted by an NBA requirement to "spend 10 seconds sitting on the bench to warm it every day before playing". Doubly so if there was a reasonable argument that it would somehow make the stadium safer for their fans.
jltsiren 4y ago
Volunteering is all about taking responsibility. If you contribute regularly to a project with many users, you can't avoid the responsibility. If you only want to express yourself by writing code without the burden of responsibility, you should contribute to something else. One thing I've learned from various volunteer projects and organizations is that good volunteer administrators are rare. Finding good people for the creative parts of the project is not particularly difficult, because creative work is inherently satisfying. Administrators are another story. Many try the job and quit, because they don't enjoy it enough to do it in their free time. Others are not suitable for the role. Some are good and motivated administrators, but they drive other volunteers away by trying to manage them. And then there are the rare ones who can be administrators and enjoy it without ruining the project for everyone else. If you manage to find one, the last thing you want to do is increasing their burden. As far as I understand, PyPI is largely a volunteer project. It works only because some people find running that kind of bureaucracy satisfying. It's their project, and they can run it any way they want. If their burden gets too heavy, they may quit, and then the project may fail. That would probably be a bigger issue than some open source contributors not liking how PyPI is run.

mtrycz2 4y ago

I find it bizarre that they don't ask for 2FA for all contributions. Possibly a historical inheritance? Edit: I now understand that they require a physical device instead of a TOTP app. Yeah, that's the line between reasonable and wtf.

lopuhin 4y ago
> they require a physical device instead of a TOTP app. Yeah, that's the line between reasonable and wtf. No, a TOTP app is also allowed.
- mtrycz2 4y ago
  Well then, that's perfectly reasonable.
  - staticassertion 4y ago
    To tack on, they're actually giving away those tokens for free for those who request one. https://pypi.org/security-key-giveaway https://pypi.org/security-key-giveaway They're being beyond reasonable. This is outright kind.
Tainnor 4y ago
> Edit: I now understand that they require a physical device instead of a TOTP app. Yeah, that's the line between reasonable and wtf. They don't.
btown 4y ago
2FA, whether TOTP or physical, comes with a per-user support burden for any organization that enforces it, because there must be a human-in-the-loop mechanism to handle "my 2FA devices were all destroyed/stolen, and others depend on me having access to my account." PyPI isn't exempt from this, despite mitigating with multiple 2FA devices, and says as much in the announcement https://pypi.org/security-key-giveaway/ https://pypi.org/security-key-giveaway/ - > Without multiple 2FA options, effect of losing a 2FA method results in the need to fully recover an account, which is burdensome and time-consuming both for maintainers and PyPI administrators. Enabling multiple 2FA methods reduces the potential disruption if one is lost. So there's a huge practical difference to PyPI of enforcing 2FA for all vs. enforcing for <1% of projects. I don't envy their position, and it's a reasonable compromise IMO. That said, it's absurd that PyPI didn't make more clear in the announcement linked above that TOTP apps are allowed. There's literally not an FAQ about the most important FAQ. They very well could have avoided the reaction from OP, and this entire debacle, with more thoughtful messaging.

dataflow 4y ago

Honestly I don't think this is a hill you want to die on. "The greater your influence, the greater your responsibilities" is something society generally agrees is reasonable in most domains, and this is just a manifestation of that principle in the case of OSS and supply-chain integrity. The principle is pretty universal in modern society though. If you see an unreasonable responsibility being placed on you, for sure, complain about that. But if you don't think the responsibility itself (2FA in this case) is unreasonable, and in fact think it should be mandated on everyone, "it's a slippery slope!" and "it's not fair!" are not going to be compelling counterarguments for most people. It goes against what people expect in society.

frenet 4y ago
Fundamentally I agree with you. But I also think it easy to get the idea that "no responsibility" is a prevailing view. Or at least that it has to be. There are plenty of people who want to do their best. I would certainly considered the author's software involvement to be part of that. It is just hard to do. And increasing hard not only because of software but society at large (like job and housing markets). So the problem exists regardless of various positions on the issue. Or put another way. If we want open source developers who favor responsibility we have to make it easy for those developers. Otherwise we only end up with people who are fine with throwing things over the wall.
CJefferson 4y ago
That doesn't seem to apply to companies -- they make billions from open source and give back little, or nothing, to the majority of the authous and packages whose work they build on. Now that's fine under open source licenses -- but if you want the "free", you also have to take the "no warranty".
TAForObvReasons 4y ago
2FA attempts to assert "the person who is publishing the package to the registry is someone that the registry expects" As a user installing from a registry, you are trusting both the publisher AND the distributor. Consider an attack where the distributor is adding malicious code to 1% of installs. The publisher is not involved in the process and (unless code signing is involved) has no influence. But if code signing is involved, why is 2FA even needed? The signatures themselves should be sufficient proof. So 2FA overall is a solution in the lens that the distributor intermediates the relationship. This need not happen. People can chuck tarballs and post signatures, establishing more direct trust compared to the indirect solution.

hanselot 4y ago

Is the whole point of this not to ensure that someone can't use your identity to produce a compromised package? When I download someone else's code its my job to make sure the code I run isn't riddled with spyware. Hence why I design my projects to rely minimally on external dependencies. Why should this burden be placed on the developer and not the user? If I buy a chainsaw and cut my arm off, is this the fault of the chainsaw manufacturer?

burnished 4y ago
You do know that bladed machinery is made with more and more safety features right? No one actually thinks "oh fuck em if they lose an arm". It just isn't a good comparison, nor a good solution.

deleted 4y ago

[deleted]

DannyBee 4y ago

"The post explicitly states that the distribution mechanism doesn't owe developers anything." But then goes on to claim otherwise in the rest of it. :) Which means that statement does not actually help your cause.