8 ms·

This is a bizarrely emotional response to me. PyPI offered to provide a security key to make the maintainer's life easier so it's hard to see this as an "entitl

by ary 4y ago

This is a bizarrely emotional response to me. PyPI offered to provide a security key to make the maintainer's life easier so it's hard to see this as an "entitled" act. When I see the core infrastructure for open source software ecosystems improve I cheer that effort on. While I am in full support of not asking too much of open source maintainers a cooperative stance makes the overall situation better for everyone involved. This could have been handled in a better way.

Wowfunhappy 4y ago
> PyPI offered to provide a security key to make the maintainer's life easier It's even easier to just leave 2FA disabled and stop maintaining the project. Which is what they did. Are maintainers obligated to support their projects indefinitely?
- pyuser583 4y ago
  There’s a moral obligation to mitigate harm caused by your project. I recently ran into a situation where a very old package caused terrible damage. I contacted the pypi maintainer. He apologized and promised to fix it. Six months later, no changes. This was a very unusual situation, as the package was the same name as a module later adopted in the standard library. The author was under the impression the package was literally uninstallable since the code hadn’t been valid Python for over two decades, including the setup script. Still wish they would delete it.
  - mwt 4y ago
    What was the license of this package?
    - pyuser583 4y ago
      I just checked - it doesn’t include any kind of license.
      - mwt 4y ago
        I'm not a lawyer or a smart individual but oh boy that's a red flag, just like several other details you offered. With the information available, it sure seems like that's a dependency that should never be brought into a project.
        pyuser583 4y ago
        Everyone agrees nobody should use this module. It’s archaic. It was being installed by a brand new programmer.
      - tsimionescu 4y ago
        Note that that means you had no right to use it at all.
        pyuser583 4y ago
        Not quite. When a package is submitted to PyPi, there’s legalese that says people can download and use it. > If I upload Content other than under an Included License, then I grant the PSF and all other users of the web site an irrevocable, worldwide, royalty-free, nonexclusive license to reproduce, distribute, transmit, display, perform, and publish the Content, including in digital form. https://pypi.org/policy/terms-of-use/ https://pypi.org/policy/terms-of-use/
        tsimionescu 4y ago
        The paragraph following that one is more important in this context: > For the avoidance of doubt, my warranty or license as set forth above applies to the Content exactly in the form provided to the PSF, and does not, other than as may be provided in the Included License, grant the PSF or any users of the website a license to make or distribute derivative works based on my Content. So yes, you have a right to download and run the package (which I didn't know about), but you do not have a right to bundle it with your software and distribute that. It is even debatable if a package that explicitly depends on the initial one, even without bundling it, would be legal - I think it probably wouldn't be, since as long as it is dependent on that package, it is arguably a derivative work of that package, which the PSF terms of service do not authorize you to make. It should go without saying, but IANAL. I'm basing my opinion on 3rd party dependency legal reviews that I've gone through at my company (from the software engineering side), and here using a package without an explicit license was explicitly prohibited.
  - deleted 4y ago
    [deleted]
kevin_thibedeau 4y ago
Forcing people to use a token that can be lost is not an improvement. This shit is going to hit the fan when Github turns on mandatory 2FA.
- OJFord 4y ago
  Well, you need more than one. And I locked myself out of the first one while (before finishing!) setting up my second, so IMO you need more than two. (It's not a great story, the tl;dr is I used a different passphrase for the second one, mixed them up, and ploughed through my 3 tries at the passphrase on my first one confident I was getting it right. I also think that default (Yubikey's) of 3-tries is insanely low, getting it wrong just once is nerve-wracking; how much easier is it to brute-force in 30? That's more guesses of pet names et al. sure but you're not brute forcing it in that. Just don't use a pet name.)
savant_penguin 4y ago
Maybe some people use their side projects to develop software without the bureaucratic crap full time jobs have. And any amount of bureaucracy is too much for his free side project
- staticassertion 4y ago
  So why publish to PyPI? I have tons of personal projects that never leave my laptop, or, at most, github.
  - deleted 4y ago
    [deleted]
  - eesmith 4y ago
    I had a package which I didn't publish on PyPI, just my web site as a "if you break it, you get to keep the pieces" sort of thing. I didn't even have a PyPI account. Someone else added it to PyPI without telling me. And people started using it from PyPI. I started getting messages about it, like PyPI developers asking maintainers to upgrade package metadata to include if it supported Python 3. That's when I realized it was on PyPI in the first place. I had to contact the original uploaded to get access to the account. One user even emailed me a question and said I had an obligation to support it, since I put it on PyPI. Damned if you do, damned if you don't.
    - staticassertion 4y ago
      I don't really see the problem. You put the code online and someone published it to PyPI. That you got what effectively amounts to spam emails because of that doesn't seem pertinent. Just block the emails. Unfortunately, putting out public communication addresses like emails does indeed invite all kinds of unwanted, unsolicited messaging. Why not just ignore that like any other spam?
      - eesmith 4y ago
        My point was that a personal project that you have on github could still be put onto PyPI by someone else, without you knowing. Even if you actively want to avoid PyPI. What you want to do about it is a different topic. Unlike most spam, I can't figure out how to select interesting email about my projects that I want to answer, from emails I don't want to read at all because they make my blood boil, like those asserting that because the project is on PyPI I'm obligated to help them. It's rather moot now as I haven't gotten emails about it for 8-10 years. Huh. As a supply-chain issue, is it important to PyPI that the person in charge of the PyPI entry be affiliated with the project, and share reputational risks should the PyPI packager add malware? That seems like an interesting vector. Find a potentially useful Python package which isn't distributed via PyPI, add an entry using a new account which looks like it's part of the project, add malware, and upload.

by ary 4y ago

Wowfunhappy 4y ago

> PyPI offered to provide a security key to make the maintainer's life easier It's even easier to just leave 2FA disabled and stop maintaining the project. Which is what they did. Are maintainers obligated to support their projects indefinitely?

pyuser583 4y ago
There’s a moral obligation to mitigate harm caused by your project. I recently ran into a situation where a very old package caused terrible damage. I contacted the pypi maintainer. He apologized and promised to fix it. Six months later, no changes. This was a very unusual situation, as the package was the same name as a module later adopted in the standard library. The author was under the impression the package was literally uninstallable since the code hadn’t been valid Python for over two decades, including the setup script. Still wish they would delete it.
- mwt 4y ago
  What was the license of this package?
  - pyuser583 4y ago
    I just checked - it doesn’t include any kind of license.
    - mwt 4y ago
      I'm not a lawyer or a smart individual but oh boy that's a red flag, just like several other details you offered. With the information available, it sure seems like that's a dependency that should never be brought into a project.
      - pyuser583 4y ago
        Everyone agrees nobody should use this module. It’s archaic. It was being installed by a brand new programmer.
    - tsimionescu 4y ago
      Note that that means you had no right to use it at all.
      - pyuser583 4y ago
        Not quite. When a package is submitted to PyPi, there’s legalese that says people can download and use it. > If I upload Content other than under an Included License, then I grant the PSF and all other users of the web site an irrevocable, worldwide, royalty-free, nonexclusive license to reproduce, distribute, transmit, display, perform, and publish the Content, including in digital form. https://pypi.org/policy/terms-of-use/ https://pypi.org/policy/terms-of-use/
        tsimionescu 4y ago
        The paragraph following that one is more important in this context: > For the avoidance of doubt, my warranty or license as set forth above applies to the Content exactly in the form provided to the PSF, and does not, other than as may be provided in the Included License, grant the PSF or any users of the website a license to make or distribute derivative works based on my Content. So yes, you have a right to download and run the package (which I didn't know about), but you do not have a right to bundle it with your software and distribute that. It is even debatable if a package that explicitly depends on the initial one, even without bundling it, would be legal - I think it probably wouldn't be, since as long as it is dependent on that package, it is arguably a derivative work of that package, which the PSF terms of service do not authorize you to make. It should go without saying, but IANAL. I'm basing my opinion on 3rd party dependency legal reviews that I've gone through at my company (from the software engineering side), and here using a package without an explicit license was explicitly prohibited.
- deleted 4y ago
  [deleted]

kevin_thibedeau 4y ago

Forcing people to use a token that can be lost is not an improvement. This shit is going to hit the fan when Github turns on mandatory 2FA.

OJFord 4y ago
Well, you need more than one. And I locked myself out of the first one while (before finishing!) setting up my second, so IMO you need more than two. (It's not a great story, the tl;dr is I used a different passphrase for the second one, mixed them up, and ploughed through my 3 tries at the passphrase on my first one confident I was getting it right. I also think that default (Yubikey's) of 3-tries is insanely low, getting it wrong just once is nerve-wracking; how much easier is it to brute-force in 30? That's more guesses of pet names et al. sure but you're not brute forcing it in that. Just don't use a pet name.)

savant_penguin 4y ago

Maybe some people use their side projects to develop software without the bureaucratic crap full time jobs have. And any amount of bureaucracy is too much for his free side project

staticassertion 4y ago
So why publish to PyPI? I have tons of personal projects that never leave my laptop, or, at most, github.
- deleted 4y ago
  [deleted]
- eesmith 4y ago
  I had a package which I didn't publish on PyPI, just my web site as a "if you break it, you get to keep the pieces" sort of thing. I didn't even have a PyPI account. Someone else added it to PyPI without telling me. And people started using it from PyPI. I started getting messages about it, like PyPI developers asking maintainers to upgrade package metadata to include if it supported Python 3. That's when I realized it was on PyPI in the first place. I had to contact the original uploaded to get access to the account. One user even emailed me a question and said I had an obligation to support it, since I put it on PyPI. Damned if you do, damned if you don't.
  - staticassertion 4y ago
    I don't really see the problem. You put the code online and someone published it to PyPI. That you got what effectively amounts to spam emails because of that doesn't seem pertinent. Just block the emails. Unfortunately, putting out public communication addresses like emails does indeed invite all kinds of unwanted, unsolicited messaging. Why not just ignore that like any other spam?
    - eesmith 4y ago
      My point was that a personal project that you have on github could still be put onto PyPI by someone else, without you knowing. Even if you actively want to avoid PyPI. What you want to do about it is a different topic. Unlike most spam, I can't figure out how to select interesting email about my projects that I want to answer, from emails I don't want to read at all because they make my blood boil, like those asserting that because the project is on PyPI I'm obligated to help them. It's rather moot now as I haven't gotten emails about it for 8-10 years. Huh. As a supply-chain issue, is it important to PyPI that the person in charge of the PyPI entry be affiliated with the project, and share reputational risks should the PyPI packager add malware? That seems like an interesting vector. Find a potentially useful Python package which isn't distributed via PyPI, add an entry using a new account which looks like it's part of the project, add malware, and upload.