Live data from Hacker News

Atomicwrites' old versions have been purged from PyPI

github.com

61–70 of 75 posts

Re: Atomicwrites' old versions have been purged from PyPI

#61

Earlier quoted context omitted.

TOTP is a minuscule security win in exchange for a significant amount of inconvenience, versus using a good password manager. If you want to prevent password reuse, add an option to use a pre-generated password as an alternative to 2FA. I think the statement "these weaknesses are implementation specific", while true, is irrelevant when 99% of people affected by this mandate (and 99.9% of 2FA users in general) are goi…

The difference between a password manager and TOTP is that TOTP is something PyPI can enforce and a password manager is not. Yes, TOTP adds very little advantage when you have an already safe password. But there is no way for PyPI to know if you're doing that or not , and they can know if you're using 2FA. > 99% of people affected by this mandate (and 99.9% of 2FA users in general) are going to use an implementation…

> Yes, TOTP adds very little advantage when you have an already safe password. But there is no way for PyPI to know if you're doing that or not.

But there is! Pre-generate a password for the user, instead of letting them supply one. This adds no extra inconvenience if you're already using a password manager, but it makes password reuse impossible.

Re: Atomicwrites' old versions have been purged from PyPI

#62

Earlier quoted context omitted.

I just checked - it doesn’t include any kind of license.

Note that that means you had no right to use it at all.

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/

Re: Atomicwrites' old versions have been purged from PyPI

#63
post #52

Earlier quoted context omitted.

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…

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?

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.

Re: Atomicwrites' old versions have been purged from PyPI

#64

Earlier quoted context omitted.

The difference between a password manager and TOTP is that TOTP is something PyPI can enforce and a password manager is not. Yes, TOTP adds very little advantage when you have an already safe password. But there is no way for PyPI to know if you're doing that or not , and they can know if you're using 2FA. > 99% of people affected by this mandate (and 99.9% of 2FA users in general) are going to use an implementation…

> Yes, TOTP adds very little advantage when you have an already safe password. But there is no way for PyPI to know if you're doing that or not. But there is! Pre-generate a password for the user, instead of letting them supply one. This adds no extra inconvenience if you're already using a password manager, but it makes password reuse impossible.

So make a proposal for them to do that.

Re: Atomicwrites' old versions have been purged from PyPI

#65

Earlier quoted context omitted.

> Yes, TOTP adds very little advantage when you have an already safe password. But there is no way for PyPI to know if you're doing that or not. But there is! Pre-generate a password for the user, instead of letting them supply one. This adds no extra inconvenience if you're already using a password manager, but it makes password reuse impossible.

So make a proposal for them to do that.

Okay, this is me proposing it! :)

I'm not the first person to come up with this idea. I think if PyPI had taken the approach of "here are our concerns, here is what we're protecting, here are some different options to make this work in the most convenient way possible", that would have been received very differently. Instead, they issued an ultimatum.

Re: Atomicwrites' old versions have been purged from PyPI

#66

Earlier quoted context omitted.

Note that that means you had no right to use it at all.

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/term…

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.

Re: Atomicwrites' old versions have been purged from PyPI

#67
post #52

Earlier quoted context omitted.

So why publish to PyPI? I have tons of personal projects that never leave my laptop, or, at most, github.

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…

> I had to contact the original uploaded to get access to the account.

That's your mistake there. Others would have left it alone or added a note somewhere.

But that begs the question: why doesn't pypi verify that uploader and developer coincide?

Re: Atomicwrites' old versions have been purged from PyPI

#68
post #52

Earlier quoted context omitted.

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…

> I had to contact the original uploaded to get access to the account. That's your mistake there. Others would have left it alone or added a note somewhere. But that begs the question: why doesn't pypi verify that uploader and developer coincide?

> Others would have left it alone or added a note somewhere.

I doubt I'm unique in this regard.

> why doesn't pypi verify that uploader and developer coincide?

How would that verification process work?

I have failed to find a PyPI requirement that they coincide.

It appears that if you have a public repo with a FOSS project but no PyPI entry then anyone is free to use your repo to create a PyPI entry. It's not quite namesquatting given that it's (at least at the start) the same code base.

I'm not sure if PyPI even allows a name transfer to you, if I read https://peps.python.org/pep-0541/#name-conflict-resolution-f... correctly:

] None of the following qualify for package name ownership transfer ... User A owns a project X outside the Package Index. User B creates a package under the name X on the Index. After some time, User A wants to publish project X on the Index but realizes name is taken.

EDIT: Someone who avoids submitting to PyPI because of philosophical objections to the PSF Code of Conduct appears to have no recourse should this happen, as the resolution process requires following the PSF Code of Conduct.

Re: Atomicwrites' old versions have been purged from PyPI

#69

Earlier quoted context omitted.

That's entirely reasonable. However, it is also reasonable for the author, who is working for free, to ignore your concerns.

I think it's completely insane to not use 2FA when available... but I also support the freedom to not maintain a piece of software unpaid. One person projects are pretty miserable.

I have ADHD. I lose things. I once had to restore access to a 2FA protected account I’d lost the token to. It took weeks of back-and-forth and involved sending personal information (selfies with identity cards) the service had no business knowing.

Never again. Especially for an unpaid personal project for which I owe nobody anything. If PyPI sent me this email, I’d immediately nuke all versions of all packages I maintain, replace with a blank/no code “upgrade” version that contains nothing but a readme explaining what happened, and close/deactivate my account.

Re: Atomicwrites' old versions have been purged from PyPI

#70

Earlier quoted context omitted.

I think it's completely insane to not use 2FA when available... but I also support the freedom to not maintain a piece of software unpaid. One person projects are pretty miserable.

I have ADHD. I lose things. I once had to restore access to a 2FA protected account I’d lost the token to. It took weeks of back-and-forth and involved sending personal information (selfies with identity cards) the service had no business knowing. Never again. Especially for an unpaid personal project for which I owe nobody anything. If PyPI sent me this email, I’d immediately nuke all versions of all packages I main…

I lose things incredibly often too(Like, losing my wallet twice and keys once, all within a 12 month period, going inside and leaving keys in the front door, needing GPS to get home 3 blocks away, etc).

If 2FA was token based as people seem to want it to be, I'd have an issue, but SMS based is enough to keep out the majority of opportunistic attackers while being recoverable. Plus, there's always printable recovery codes with Google at least.

Post reply on HN