Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Atomicwrites' old versions have been purged from PyPI

github.com

Post reply on HN
Print view View original

51–60 of 75 posts

Re: Atomicwrites' old versions have been purged from PyPI

#51

Post by tsimionescu »

Wowfunhappy wrote: post #22
krasin wrote: post #19

Earlier quoted context omitted.

Yep. Both parties here are within their rights. It's the HN comment about entitlement of the maintainer that I was responding to.

I think both parties are within their rights, but I also think this is a stupid move on PyPI's part. Maintainers are already working for free; start making them jump through hoops and some will decide it's all too much work and leave. I think it would be much better to throw up a warning (potentially a loud one) when a dependency is maintained by someone without 2FA.

Packages being taken over because of stolen credentials creates a maintenance nightmare, and bad publicity, for PyPI itself. As such, they have every right, and a reasonable need, to require 2FA. In contrast, the maintainers of PyPI don't lose too much if a few projects choose not to use the platform anymore. Remember, you're not paying PyPI anything either, so the fact that it may inconvenience your own projects, whether free or proprietary, is not their problem.

Re: Atomicwrites' old versions have been purged from PyPI

#52

Post by eesmith »

staticassertion wrote: post #34
savant_penguin wrote: post #32

Earlier quoted context omitted.

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

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 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.

Re: Atomicwrites' old versions have been purged from PyPI

#53

Post by OJFord »

kevin_thibedeau wrote: post #23
ary wrote: post #13

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 in…

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.

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.)

Re: Atomicwrites' old versions have been purged from PyPI

#55

Post by moreira »

bmacho wrote: post #54
tsimionescu wrote: post #50

Earlier quoted context omitted.

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

In which country?

Almost all of them. All rights are reserved by default without you having to do anything in most countries. Hence open source licenses.

Re: Atomicwrites' old versions have been purged from PyPI

#56

Post by staticassertion »

eesmith wrote: post #52
staticassertion wrote: post #34

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 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?

Re: Atomicwrites' old versions have been purged from PyPI

#57

Post by mwt »

pyuser583 wrote: post #41
mwt wrote: post #40

Earlier quoted context omitted.

What was the license of this package?

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

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.

Re: Atomicwrites' old versions have been purged from PyPI

#58

Post by naniwaduni »

staticassertion wrote: post #31
naniwaduni wrote: post #26

Earlier quoted context omitted.

While there are scenarios where 2FA can maintain security where a password is compromised, it's absolutely true that for a large swath of practical threat models, almost the entire benefit of 2FA comes in the form of assigning the shared secret instead of letting the user pick a weak and/or widely-reused password and the "having a second factor" bit doesn't really factor into the picture in any meaningful way.

These weaknesses are implementation specific. FIDO2/U2F is unphishable, requires proof of presence, and is a significant security win over a strong password.

I'm not calling it a weakness. I'm saying that the alleged advantages of the 2F in 2FA don't normally matter to people who just want to their shit to work.

Re: Atomicwrites' old versions have been purged from PyPI

#59

Post by pyuser583 »

mwt wrote: post #57
pyuser583 wrote: post #41

Earlier quoted context omitted.

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

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.

Everyone agrees nobody should use this module. It’s archaic.

It was being installed by a brand new programmer.

Re: Atomicwrites' old versions have been purged from PyPI

#60

Post by staticassertion »

Wowfunhappy wrote: post #48
staticassertion wrote: post #47

Earlier quoted context omitted.

OK? So more people use TOTP and there's a marginal security win. And maybe a few use a token, and there's a significant win.

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 with these weaknesses

Time will tell. PyPI is giving away free keys, presumably to encourage adoption of the safer option.

I'm actually very happy to see maintainers go. If they weren't willing to enable 2FA I worry about what other issues their software poses.

Post reply on HN