Congratulations: We now have opinions on your open source contributions

https://lucumr.pocoo.org/2022/7/9/congratulations/

by the_mitsuhiko • 4 years ago

242 202 4 years ago

lucumr.pocoo.org

As someone who likes 2FA, I definitely see the author's point here. It seems kind of unfair to say "a lot of other people now use the thing you've been uploading here, so now here's a bunch of new rules you have to follow".

__s2• 4 years ago

However, just as open source developers don't owe downstream, package repositories don't owe open source developers. The package repository isn't preventing the developers from continuing to publish their packages elsewhere

If I'm an open source developer who starts uploading malicious packages to a repository they aren't obliged to not delist my malicious packages. PyPI is proactively considering critical packages without 2FA protection malicious

cowtools3• 4 years ago

PyPI is proactively considering critical packages without 2FA protection malicious

And it's ridiculous for them to do so. How can they verify that the 2FA program is not just being run in a virtual machine? At the end of the day it's the maintainer that decides the security of the package.

the_mitsuhiko5• 4 years ago

Author here.

The package repository isn't preventing the developers from continuing to publish their packages elsewhere

You are right that the package index doesn't owe developers anything and this is in fact something I called out explicitly in the post. However I believe your point about "isn't preventing" is not quite accurate. In order to participate in dependency trees in most ecosystems you need to be on "the" index. Yes, you can sort of create dependencies to stuff off PyPI but this breaks down really quickly. Because of this PyPI has a special role to play.

This is not too dissimilar to discussions we are having about freedom of speech and similar things at the moment and I think the answers are much more nuanced and complex than it might look on the surface. If PyPI were to start putting restrictions on some people publishing or accessing packages, we had a much bigger challenge on our hand. To be clear: this discussion is not about that, but the "just move somewhere else" type of answer I do not believe is a good option to dissatisfaction with the primary index.

jka6• 4 years ago

In particular, if package indexes start introducing additional requirements for developers, as mentioned in the article, then I do worry that it could risk moving an unreasonable level of burden onto developers (who may initiate or develop code purely for their own enjoyment).

Currently the "critical package" categorization may offset most of the likelihood of that occurring, although I'd expect there could be problems for some projects even so.

I wonder whether PyPi considered making 2FA-at-publish-time optional and instead offering a question of 2FA-at-package-install-time.

In other words: "pip install --2fa-signed-packages-only" or similar.

It's possible they didn't, or weren't able to, because the ecosystem is already widely deployed and many package version upgrades (including transitive dependencies) occur automatically.

Roughly speaking: I like the author's suggestion (quoted below) of making the the software package ecosystem an immutable (content-addressed?) space, where policies and attestation about whether to use those packages is opt-in based on rules-based overlays. That'd be ambitious but technically feasible, I think.

"So if I were to wish for something, then that the index has no policies beyond immutability of assets, and instead we use an independent layer of the index to enforce policies."

jka6• 4 years ago

A correction/clarification since writing the parent comment: publication of packages requires an authentication token, and does not require an interactive 2FA challenge. Generating a suitable token for package publication, however, does.

(that implies that a naive implementation of '--2fa-signed-packages-only' flag would mean 'packages that were published using tokens that were generated by a 2FA-authenticated user; possibly a subtle distinction, but maybe worth mentioning)

Fordec• 4 years ago

We've seen it with social media and content moderation. It's just a little ahead of the game because more people means entities come to the conclusion faster.

Content hosts have hosting rules. Don't like updated rules? Move to another network or self host. You as a platform user have to weigh the pros and cons that come with that decision.

Personally I have stopped contributing to open source due to consumer expectations around free work. My passion projects are now all private and they are all mine or employers who gain from my learnings by paying me. If that's a loss to society, well society can figure out the cost-benefit analysis and get back to me with a better proposal.

Side not: upon going down this rabbit hole, I find that Facebook/Zuckerberg is their primary sponsor[0] and the fact that auth is becoming more of a thing leaves me with zero surprise

[0] https://pypi.org/sponsors/

woodruffw9• 4 years ago

Facebook is not PyPI’s “primary sponsor.” To the extent that any company could legitimately claim that, it would be the one that provides PyPI’s CDN for free.

Here is my first-hand account: the money that Facebook donated to PyPI was used to pay me to implement 2FA (and a whole bunch of other things). It wasn’t used for any of the current rollout, to the best of my knowledge.

avgcorrection• 4 years ago

Personally I have stopped contributing to open source due to consumer expectations around free work. My passion projects are now all private and they are all mine or employers who gain from my learnings by paying me. If that's a loss to society, well society can figure out the cost-benefit analysis and get back to me with a better proposal.

This is a very rational decision. In contrast, I think it is irrational when people keep contributing to OSS while at the same time nurturing resentment towards people who feel entitled to their help, support, or whatever else.

Groxx• 4 years ago

Particularly when using a license that explicitly says "you're on your own":

THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED.

If you want support, availability, or timely fixes, you need to form a business relationship of some kind. Which almost certainly involves paying someone.

That has not happened here (at least in the vast, vast majority of cases), so I think they're entirely fine stopping updates / going elsewhere / removing their package, if they want. Anyone who falls apart due to that hasn't been doing due diligence. It totally sucks for them, but that doesn't mean they get to force their issues onto others.

morelisp4• 4 years ago

I wonder, is 2FA mandatory for all privileged access to the index itself? To all the services it uses to run? To its code? To all its dependencies? To Python itself?

TazeTSchnitzel• 4 years ago

Reminds me of https://news.ycombinator.com/item?id=27106448

simonw• 4 years ago

This is a really interesting field of discussion, because there are such strong arguments in both directions. I don't think there's a single right answer here.

I personally come down more on the side of "registries should have policies limiting the damage that their participants can cause", but I absolutely respect the arguments that "volunteers working for free should not have additional restrictions placed on how they do their work".

Tainnor9• 4 years ago

This is laughable.

First of all, it's the slippery slope fallacy. 2FA is not a burden and you can't get any reasonable person worked up because of it. The insinuation that this might lead to other sorts of control is pointless; this possibility has always existed.

Second of all, package indexes have a responsibility to the programming community as a whole and as such I do expect them to make some reasonable demands. This is not infringing on open-source developers' freedom, since nobody forces them to release their code on an official package index.

This post really reads like a storm in a teacup.

throwawaybutwhy2• 4 years ago

Not a storm in a teacup. Being forced to accept unvetted electronic devices from a 'Foundation' instead of using TOTP rings a whole lot of alarm bells.

* How do we know that these ain't fitted with GPS trackers?

* Why are maintainers forced to give up their snail mail addresses?

* How will the keys be re-issued? Who's going to pay for this?

* Oh, and there's still the silly geo-fencing issue: 'Austria, Belgium, Canada, France, Germany, Italy, Japan, Spain, Switzerland, United Kingdom, and the United States'

Tainnor9• 4 years ago

Nobody is forcing anyone to use particular devices. Those are optional. Only 2FA itself is mandatory.

duskwuff• 4 years ago

You are assuming that the contributors are required to use these specific devices. This is incorrect. PyPI is offering free U2F devices to a subset of the affected developers, but they are free to use their own U2F devices (or a TOTP client) instead.

Oh, and there's still the silly geo-fencing issue

The list of countries makes this sound like an export control issue. It's a legal restriction, not a deliberate choice PyPI made.

echelon2• 4 years ago

This last decade has played host to some of the most fascinating series of debates, an almost visceral push and pull, concerning individualism vs collectivism, distribution of control vs centralization of power.

- COVID vaccine mandates

- Cryptocurrency

- Deplatforming

- Abortion

- Closed platforms beating open web

- Monopolies controlling tech

- One party governments gaining in power

Strict control over package indices is one manifestation of this. Controlling a blast radius (safety) vs unlimited, unfettered publication (freedom).

Power structures are everywhere.

Tainnor9• 4 years ago

How anyone can get this worked up because of 2FA is simply beyond me.

I guess some people just have to feel like rebels all the time.

jka6• 4 years ago

It seemed clearly-written and thought-provoking to me; the author doesn't claim that 2FA is a burden, either.

Writing and distributing software should be straightforward so that everyone can participate. And consuming software should be safe so that people and infrastructure are protected. Finding a security model that achieves both should be the goal.

PyPi appear to have walked a reasonable line on this so far, and it's worth considering and discussing what the future could be like.

ev14• 4 years ago

Another reasonable point here is that pypi is also offering package owners ~$75 (edit: didn't realise they were sold in 1-packs now) in modern usb-c fido2 keys if you have one that is now marked as critical.

hgs3• 4 years ago

Open Source doesn't mean free. Package repositories could require payment for premium/vetted packages. In this scenario both the OSS developer and index maintainer get paid.

SoftTalker• 4 years ago

Once you start accepting payment for something, more responsibilities are implied.

BiteCode_dev4• 4 years ago

From the article:

The message to me as a maintainer is quite clear: once a project achieved criticality, then the index wants to exercise a certain amount of control

I don't think that's the definition of control. Pypi gains no power with this, only more work.

And 2FA is really not a big deal.

One could imagine that an index would like to enforce cryptographic signing of newly released packages.

Yes. Please yes.

Letsencrypt was a boon to the web.

Having a quick way to sign your package to send it so pypi would be a great thing.

This is a long article over nothing.

nibbleshifter3• 4 years ago

Having a quick way to sign your package to send it so pypi would be a great thing.

I guess we just need to make signing easy then.

Which remains a hard problem.

Tainnor9• 4 years ago

What, exactly, is hard about signing?

dlor3• 4 years ago

We've been working with PyPI to help integrate Sigstore, which makes signing (and verification) easier!

sigstore.dev

BiteCode_dev4• 4 years ago

We used to say that about https, and now we got letsencrypt.

cowtools3• 4 years ago

2FA is a pain in the ass and provides minimal extra security. The reason why companies employ it is because their users are incompetent and will install malware on their desktop OS, so they shift the burden of security to locked-down mobile operating systems like Android and iOS.

If an experienced user does not want to use 2FA, they will run the 2FA app in a virtual machine and automate it. You can't force them to 2FA but you can inconvenience them and tie them down to a phone number, SMS, or locked-down hardware (through remote attestation).

Letsencrypt was a boon to the web.

Letsencrypt and the existing PKI structure just forces everyone's eggs into a single basket, Ripe for exploitation from the government.

BiteCode_dev4• 4 years ago

In this particular case, Pypi is giving away hardware security key.

I have 3 of them, it is secure and convenient.

BiteCode_dev4• 4 years ago

With root certificates, gov already have complete ability to MITM your https connection.

DannyBee3• 4 years ago

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.

the_mitsuhiko5• 4 years 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). 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.

Tainnor9• 4 years 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

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.

jnovek2• 4 years 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?

mtrycz22• 4 years 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.

dataflow5• 4 years 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.

hanselot• 4 years 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?

DannyBee3• 4 years 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.

x86x87• 4 years 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_White4• 4 years 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.

rrdharan2• 4 years 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”).

staticassertion16• 4 years ago

If you walk into my house and I ask you to take off your shoes, you can turn around and walk away. I am well within reason to make that demand - it's my house.

krab• 4 years 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• 4 years 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.

staticassertion16• 4 years 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.

bastawhiz3• 4 years 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.

lopatin• 4 years 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.

dlor3• 4 years 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.

perrygeo2• 4 years 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.

hoten• 4 years ago

Slippery slope nonsense. Use 2 factor. Jeez.

colechristensen• 4 years ago

That’s a lot of complaining about having to log in with 2FA. You don’t owe a package index anything and a package index doesn’t owe you anything and if either of you don’t like what the other is doing you can go your separate ways. You’ll each have your own conditions for staying together and there’s nothing wrong with that.

As an open source contributor, the world doesn’t owe you participation in an ecosystem only in the way you want it. If you don’t want to play by others rules, don’t.

ctoth2• 4 years ago

Perhaps your ad blocker or something else blocked out the paragraphs of the article where OP specifically addresses this point. I will paste it below. It is quite clear this is not just about 2FA but instead about a line being drawn which makes a new, special class of package that didn't originally exist when the author started work.

There is a hypothetical future where the rules tighten. One could imagine that an index would like to enforce cryptographic signing of newly released packages. Or the index wants to enable reclaiming of critical packages if the author does not respond or do bad things with the package. For instance a critical package being unpublished is a problem for the ecosystem. One could imagine a situation where in that case the Index maintainers take over the record of that package on the index to undo the damage. Likewise it's more than imaginable that an index of the future will require packages to enforce a minimum standard for critical packages such as a certain SLO for responding to critical incoming requests (security, trademark laws etc.).

travisjungroth• 4 years ago

I thought at first this was a slippery slope fallacy, but it's not exactly. The author realized the power that package indexes have and wants a different system. Even suggests an alternative!

This is a very different argument than "if they do this, next they'll do that" or "by doing this they'll have more power". People often mistake the exercising of power with its existence.

Here's an example: In 2016 a huge amount of Ethereum got hacked. So much so, the creators of Ethereum decided to fork it, unwind the transactions and call that new chain Ethereum. The original chain is Ethereum Classic.

An argument I've heard is that this was a bad move because it sets a precedent and "made the chain not really immutable". If something is immutable as long certain people don't do things they can totally do, then it's not really immutable. (Jeez I don't actually want to start a fork flamewar, just contrasting the logic. Fingers crossed).

frenet3• 4 years ago

I do think this is a bit of a billion dollar question. The way Linux distributions mostly does it is some form of long-term support release which gets less updates but still security updates. Burdening the maintainers more than the developers. However the amount of complexity of everyone trying to do that at the same time is not only crazy but also a real limit on progress.

Still something like that could be somewhat of a solution. You don't need to use for example 2FA but then you also don't get to publish to everyone today. Then you have to do a security update which would require it.

submeta• 4 years ago

Much ado about nothing.

raverbashing2• 4 years ago

I don't like the drama about this. It really is not what being a maintainer should be about.

Open source developers need to learn how to be professional.

We can complain all day about packages that don't get recognition, where the maintainer struggles to maintain it and then we wonder, where's the professionalism?

Enable your 2FA. Allow users to support you financially (support agreement, etc).

I do not chose to create a “critical” package

To the winner, the spoils. Fame has a cost. Drop your package and ask someone else to maintain it if you can't.

yjftsjthsd-h• 4 years ago

Open source developers need to learn how to be professional.

No, professionals need to be professional. Some FOSS devs are professionals and should act like it, but many FOSS devs are just hacking around in their spare time and don't owe anyone anything; certainly they're under no obligation to be "professional" with their side projects.

raverbashing2• 4 years ago

Yes, nobody needs to be a professional, and nobody has to brush their teeth in the morning neither

Feel free to not publish through PyPi either

"Maintainers" who can't be bothered to activate 2FA make me lose trust in their code quality.

crumpled• 4 years ago

The index thinks that a widely- adopted package looks like a tempting target for hackers to inject malware. They need to help avoid that, for ethical, legal, and business reasons. Signing the release sounds perfectly reasonable too.

HOWEVER

I do think that a lot of the committing here is focused too much on the thing that got the author thinking (2FA), and focused too little on what the author was thinking about.

It is worth noticing that there's a potential for a package index to leverage your user base against you and start making demands. Of course you could walk away from pypy, or npm, but that's almost like suggesting you walk away from the Google Play store if you developed android apps. I like this article as something to keep in the back of your mind when you look at the future of package publishing.

How likely will this repo/index be to demand money from me some day when my user base gets large enough? Can I be delisted because of a new content policy?

franciscop2• 4 years ago

Exactly, I'm in the same boat as the author and you, where the 2FA is just a mild inconvenience (I travel a lot, no fixed sms, have lost too many yubikeys). However indexes forcing authors to use 2FA has open my eyes to how much control they have; if they required tomorrow to identify with a national ID, or pay $10/year for the top 1% of authors they could easily do so (e.g. any action not "too" drastic to have a massive backlash, meaning it's draconian but only for very few). This could go virtually in any direction and they have a massive amount power, and that feels very scary indeed.

I've invested 10s of thousands of hours in writing open source, which I'm very happy to share with the world, and while I have multiple backups being banned or unable to use npm would def be a tragedy for me.

massysett2• 4 years ago

The index didn’t force the devs to do anything. The developer can just stop uploading packages.

Years ago software was just distributed by the developers themselves on their own websites, or by Usenet, or even by floppy disks.

It may well be that the developer wants to be on the index and is willing to pay. In that case, OK. Maintaining an index is not free, so if the indexer needs to charge somebody, it could be users, or it could be developers.

__alexs2• 4 years ago

I think it would be perfectly reasonable for these platforms to start demanding money. As a consumer and a producer of packages they provide a huge amount of value. Yes I could run my own but it's deeply inconvenient in many ways, that's part of where that value comes from.

nmstoker2• 4 years ago

Whilst not impossible, as soon as that's done, it adds all sorts of unintended consequences

pishpash• 4 years ago

Then make sure the index is owned by a cooperative of all the developers (with appropriate ground rights), not by some arbitrary third party?

staticassertion16• 4 years ago

PyPI is so easy to self host it's almost a joke. You can run a single python simple http server (one command) and use specific file system layout and you have a compatible pypi.

If there is such a significant mismatch in what pypi is going for vs contributors, people will migrate to another solution.

pas• 4 years ago

there's a big gap between "meh it's okay" and "pypi really goes above and beyond to serve the package developers and the users too".

it's strange (unexpected? totally expected? sad?) that the for profit npm (which started out as the butt of every supply chain joke) seems the most dev friendly.

eg. npm has namespaces (and neither pypi nor rust's crates.io does. and the Rust dev experience is usually considered sublime, and the whole decision making in Rust land is [was?] very dev-driven)

otikik• 4 years ago

All my open source projects have a “money back” guarantee. They are also free. What I mean is that I am as hands-off a maintainer as one can be.

Still, Having to use 2FA to publish on a platform doesn’t bother me too much. It’s their platform, my personal inconvenience of using 2FA is overridden by me not having to maintain the platform.

hartator• 4 years ago

Specially at the end of the day, 2FA really means auth by your phone as you can always reset your password.

It’s like remembering a password, make it strong, and keep is safe has no value.

staticassertion16• 4 years ago

Feel free to just... not publish to pypi.org. You can run your own pypi if you'd like, it's pretty trivial. Or you can just put your code on github. Or pastebin. Or nowhere.

As for cargo-vet vs 2fa, as the article mentions (but I think bears emphasis), they solve different problems.

Sorry but I just do not care at all about this "burden" that you may feel because you've been asked to enable 2FA for a site that hosts your code for free.

A lot of this article also seems to boil down to some sort of slippery slope. 2FA today, package signing tomorrow, the end of the world next week? I'm unconvinced.

Ultimately,

I think as an Open Source developer who is using the index for free, I can't demand much from it.

I feel like the article could have been this one line, and then there could have been a separate post discussing the merits of 2fa vs vet.

mschild• 4 years ago

As for cargo-vet vs 2fa, as the article mentions (but I think bears emphasis), they solve different problems.

I disagree. On the surface and a technical level cargo-vet and 2fa do different things, yes. However, the intended effect here is very similar. PyPi is asking some authors to use 2fa because they want to avoid popular packages getting compromised. Cargo-vet tries to achieve the same end result through a different method.

A lot of this article also seems to boil down to some sort of slippery slope. 2FA today, package signing tomorrow, the end of the world next week? I'm unconvinced.

While unlikely, it does bring up the question of how much control a package index, or similar org, should be able to exert control over contributors. In theory, its their index and they are hosting your code for free so they can do as they please. On the other hand, they are the de-facto standard and are, in my opinion (perhaps a bit far fetched and certainly not as malicious as Google) the Play Store of the python world.

staticassertion16• 4 years ago

I suppose so. To me, 2FA is solving the "who manages the package" whereas vet is a solution for distributed auditing of what the package does. Ultimately their goals align in that they're both trying to prevent an attacker from manipulating the code and having that successfully deploy to users' systems.

I think they're just so wildly different in every way that it's hard to say they're solving the same problem unless you zoom way out.

The reality is, however, that the `vet` approach has never been shown to work at scale, and 2FA has. 2FA has decades of implementation work, threat modeling, etc. `vet` is a one off tool for Rust and no integration into the wider ecosystem.

I would love to see a `vet`-like tool for PyPI, I would love that, but saying "we could have used vet" is really glossing over a lot of practical issues.

. On the other hand, they are the de-facto standard and are, in my opinion (perhaps a bit far fetched and certainly not as malicious as Google) the Play Store of the python world.

Yeah, sure. At the same time, why is it that open source maintainers get to say "I have literally 0 ethical responsibility to do anything ever"? That's the status quo - maintainers who distribute their code through these repositories owe you nothing. We accept that. But we don't hold the same thing true for the package repository? They suddenly owe the maintainers something?

More directly, maintainers have their goals, repos have their goals, users have their goals. They'll align where they can, but no one is beholden to anyone else, and we can't really change that.

raggi• 4 years ago

2fa aims to reduce the volume of released attacker controlled code prior to release.

vet aims to reduce the volume of attacker controlled code and accidentally dangerous code after release.

they operate on distinctly different timelines, against different threat models, with different actors.

robotresearcher3• 4 years ago

The symmetrical position:

‘I think as the distributor of open source developers’ work, I can’t demand much from them’

The question is about maintaining a sustainable balance in the in-kind value each side perceives.

Tainnor9• 4 years ago

PyPI is not demanding that OS devs publish their code on their platform.

staticassertion16• 4 years ago

That's not the symmetrical position. PyPI demands nothing of anyone. It provides a free service with terms of use.

dataangel• 4 years ago

I think 2FA, if it mandates SMS use, is a burden for certain package types. Imagine a package that helps you write software that bypasses the Great Firewall. There is occasionally value in anonymously authored software, and cell phones to degrees that vary by country reveal your identity and at the very least give a central authority knowledge about your location.

ev14• 4 years ago

PyPI is correct 2FA: TOTP, WebAuthn etc

radus2• 4 years ago

In that scenario though I think there are reasons why one might avoid package repositories such as pypi. For instance, say a censorship avoidance package is popular on pypi - what happens when whatever authority comes knocking?

I would think that it would be more secure to provide anonymized distribution as well. Of course, that means that you lose some convenience and reach, but that’s a common trade off in scenarios that have elevated security needs.

woodruffw9• 4 years ago

PyPI does not use SMS 2FA. It only supports WebAuthn (which is preferred) and TOTP.

Source: I implemented PyPI’s 2FA.

anothernewdude2• 4 years ago

Exactly, just let the version on pypi bitrot and get security issues. It's a great win for their policy.

alfiedotwtf• 4 years ago

complex passwords yesterday, 2FA today, package signing tomorrow, reproducible builds the next.

Don't threaten me with a good time.

bjt2n3904• 4 years ago

There are certain impossibilities in the world, like the halting problem, and DRM: "As the author, I wish to sell my work. But I don't want anyone to copy my work, and redistribute it without my permission -- or use it in a way that I disagree with."

Such a thing is an impossible ask. No technological means can prevent this from happening -- though many have tried and failed. It always results in a repressive and totalitarian ecosystem.

I think that pypi is trying to accomplish is in this category. It results in things like the leftpad.js incident.

The goal is always some specious form of "harm reduction", trust, and safety. These can't be obtained by technological means, but they can be produced.

bbayles• 4 years ago

FWIW, I also maintain a "critical" package, and I'm happy that the index is requiring 2FA for it.

zbird2• 4 years ago

First, thank you for your contributions :)

I agree with the author that the request is unwarranted. As far as I can tell, most licenses typically have a clause that waive any damages caused by the software along the lines of 'THIS SOFTWARE IS PROVIDED BY COPYRIGHT HOLDER "AS IS"...', so there is absolutely no moral obligation on behalf of the author. e.g:

https://choosealicense.com/licenses/bsd-4-clause/

Absolutely agree that PyPI, seeing that it benefits from the contributions of unpaid developers, doesn't really have a moral right to exert this kind of control over developers. Basically, corporations are free-riding on the unpaid work of developers, and now they have decided that some packages are "critical" and require more unpaid attention. Here, have a Google 2fa key, the proprietary firmware will surely be convenient.

I also kind of see the point others are making regarding the OP's presumed entitlement; nobody is forcing them to publish on PyPI. Yet, PyPI is the go-to distribution channel for Python, so if you want to contribute anything, it is reasonable that you do it through that channel. It's the similar kind of network effect that happens with 'social' networks.

bastawhiz3• 4 years ago

Yet, PyPI is the go-to distribution channel

If the go-to distribution channel is run rampant with supply chain attacks, doesn't that kill the distribution channel? Surely the philosophical argument against forcing maintainers to use 2FA is at odds with the extremely real existential threats to the longevity of the service?

zbird2• 4 years ago

There are many other problems beyond what 2fa can solve, so this discussion focused solely on 2fa is missing the forest for the trees. Specifically, one can get malware into a package via (a) publishing a malicious version of the package using stolen credentials, or (b) having the malware merged in a PR. 2fa only protects against the first case. Also, pulling in third-party dependencies into a software project without reviewing them is a terrible way to develop software, so the responsibility does not fully lie on the provider of the package (and, as I mentioned earlier, there is legally no responsibility on them anyway as per many of these free licenses.) So there are many more ways we can kill a distribution channel that 2fa cannot solve. Forcing 2fa on a select number of packages to suit the whims of corporations is still a shitty move. Though I still agree with you that, in general, more guarantees on the origin of a package is for the best.

anothernewdude2• 4 years ago

and yet npm still keeps being used.

secondcoming• 4 years ago

I only just now realised that PyPI stands for Python Package Index.

ctoth2• 4 years ago

Disappointed to see you folks get caught up on the question of 2FA and not a single mention of @mitsuhiko's discussion of solutions, such as vetting as a service. Personally I think this is a very interesting idea, separating distribution from verification, and allowing for people to set their own criteria for vetting/verifying code. It would work well and scale from hobby projects all the way up to corporate behemoths. But sure, let's get stuck talking about 2FA and how slippery slope is a fallacy as if we haven't each one of us seen this sort of thing before.

staticassertion16• 4 years ago

Disappointed to see you folks get caught up on the question of 2FA and not a single mention of @mitsuhiko's discussion of solutions, such as vetting as a service.

Comparing 2FA and vet is done at the end of the article and isn't, in my opinion, overly relevant. It's more of an example of "we could have solved this at a lower burden", which I don't believe is actually true (and I'd happily discuss that), but more importantly doesn't change the actual important bit of the article, which is about the relationship between users, maintainers, and distributors.

kevin_thibedeau• 4 years ago

Pip can install from a Git URL. If the author wanted to make a stand they can deprecate their PyPI package and support decentralized distribution.

belfalas• 4 years ago

I felt this was a thoughtful writeup!

It does seem reasonable that if someone publishes an open source package to an index for distribution, they are accepting that the index may place some constraints on them once their package hits critical mass. So in this case once the authors package received greater than X downloads, they were required to log in to the index with 2FA in order to continue to publish releases. From how I read the article the author was okay with all of this and even reasoned through the requirements.

I think the next key point is subtle: at what point does a package become 'critical' enough that an index might feel empowered to take it over in the name of 'the ecosystem' or 'the community'?

To my mind the question comes down to: who are the people running the index and what are their economic interests? How do I know I can trust the index will not suddenly impose draconian rules or abscond with all the assets wholesale?

Considering where we are in 2022 this is worth considering for more than five minutes. Traditional supply chains are being disrupted and there is an incredible geopolitical realignment taking place across the globe at the moment. Black swan events in a way are the new normal and we cannot take things we used to know for granted (e.g., how freenode changed so quickly and of course how the pandemic caused the world to shift on a dime).

politician2• 4 years ago

How do I know I can trust the index will not suddenly impose draconian rules or abscond with all the assets wholesale?

You can’t. Look at what happened to freenode where the admins sold rights to the server to a private buyer who immediately implemented strict controls on how channels operated.

The same trust problem that PyPI are trying to solve with maintainers of critical packages applies to the index itself.

__alexs2• 4 years ago

I also got one of these emails as I created a package that apparently gets millions of installs these days. Personally I have zero issue with PyPi putting more restrictions on these packages, I wish they would do more. As a maintainer it can help me be less likely to screw up.

Ultimately I feel no obligation to contribute to open source or continue to maintain this software. (In fact others have taken over a lot of it for years.) It's a thing I chose to do, I bare the responsibility for those actions. If it gets too much work for someone we should have no bad feeling towards them for walking away.

However maintainers get a lot of bullshit but PyPi are really not contributing to that. There is a slippery slope argument here that I think is just nonsense and in particular I trust people like dstufft and the rest of the team to do their best to avoid contributing to it.

So PyPi team, thanks for this, please feel free to do more.

Yes the package repos have a ton of power. We have a kind of social contract with them to act responsibly so far but all of these platforms are built on a giant pile of donations and free labour. If that contract is violated we'll start finding new solutions. Up until that point I'm happy to let the people with the sweat equity do what they think is right.

kazinator• 4 years ago

If you maintain a package within the framework of a certain project, using its tools and repositories, they get to dictate the access control and other rules.

If you don't like how they run that, then develop whatever you're developing under some alternative hosting (perhaps self-hosting). Let someone else pull from your repository and update the packages elsewhere. That someone will play by the rules: using 2FA if the package is critical or whatever. You, the upstream, do not have to; you don't have to have any interactions at all with the downstream project.

The downstream project doesn't impose rules and procedures on you in order to impose undeserved obligations upon an open source developer, but because have privileges to publish changes. It doesn't matter whether or not you're the developer of those changes.

xg15• 4 years ago

On Friday I along many others in the Python community "congratulated" me on having created a critical package. Once packages are within a certain level of adoption compared to the global downloads, they are considered critical.

Does he at least get a blue checkmark next to his account name?

givemeethekeys• 4 years ago

Hey, have at it. Infact, I hope your opinions are as controversial and viral as possible. As they say, "no such thing as bad publicity" :D

perrygeo2• 4 years ago

I really don't understand the "critical package" dichotomy. Why not 2FA for everyone? If it's a best security practice, just say so. Set a cutoff date after which every PyPi author needs to comply. Targeting only the authors of popular packages feels weird and arbitrary.

eesmith• 4 years ago

Like many big changes, it's often better to do small-scale testing first. That gives a chance to learn more about the failure modes before switching to a larger-scale or full changeover.

If I wanted to make the change-over, I would start with the people with a lot of experience, the ones most likely to be paid to do this extra work, and the ones most likely to be interested in supply-chain security.

That seems decently well correlated with being the most popular downloaded packages, and I can't come up with a better initial sub-population.

creatonez• 4 years ago

This is a really boring complaint. 2-factor authentication is not hard or time consuming.

If they start pushing other requirements, sure, I'll complain. Further requirements should take place on another independent 'vetting' layer, like the author suggests. But right now, there's no sign of excessive requirements in the future.

bastawhiz3• 4 years ago

For all the heartache in open source right now, taking a hardcore stance against MFA is a weird hill to die on

petters• 4 years ago

They should just have required 2fa for everyone.

greatgib• 4 years ago

I received this email and did not appreciate it too much also.

It is like: "Congratulations, you are designated as critical, as one of the top downloaded package"

So you think, awesome, what is my prize? "You won the right to have more restrictions on your account"

I think that it would be ok for the index to show which package are 'safer' but indeed not do it like that.

In the best world, I would imagine something like that: Your package is tagged as not 2fa safe. Users can pledge a donation to the maintainer to motivate him to use or keep using 2fa. That he can't get without using 2fa. Something like that so the maintainer does not have all the burden that only benefit to 'free' users.

tonnydourado• 4 years ago

I used flask a lot and love Armin, but, with all due respect, this is an overreaction. The world is on fire and pypi.org decided to throw 1 (one) bucket on it. There's no slippery slope lurking in the shadows, "The Index" is not some mythical beast with unknowable intent, it's mostly other overworked and underpaid open source developers. It will be fine.

jrockway• 4 years ago

I think I agree with the author that this is potentially a slippery slope. 2FA alone is a great idea, passwords are one of the worst inventions in human history, but it only protects against one supply chain attack -- having your password guessed. What happens when you say "fuck everything" and upload intentionally broken code? We're going to need a mental health assessment. What happens if you're in debt and someone pays you to upload broken code? We're going to need a background check. What happens if malware modifies the code you upload? We're going to need to run this antivirus software that sends all the files on your workstation to our Corporate Overlords. I mean, if you don't agree with all of that, are you really SERIOUS about being a software engineer in your spare time?

The intersection of hobbyists and corporations is a mess. At the end of the day, most people writing open-source software just wanted to scratch an itch. They could be doing anything they want in their free time, and their top choice is probably not to support some Fortune 500's infosec OKRs. It's important to balance modern security requirements with the fact that there is a human being on the other end who is not your employee.

rogers12• 4 years ago

Getting your computer hacked is a contagious disease. From there, attackers can infest other machines and run social engineering attacks against your friends. Maintainers of popular open source projects are super-spreaders. They can infect a huge number of other people.

2FA is a vaccine that mitigates or prevents spread of this disease. It is unconscionably selfish to refuse to harden your accounts just because it's a little inconvenient to you.

pwdisswordfish0• 4 years ago

The apostrophe use in this post is out of control.

woodruffw9• 4 years ago

I understand the author’s concern here, but I want to point out a couple of things (both specific to PyPI and more general):

* Package indices have always had opinions about their users’ contributions. Most indices have revocation/yanking policies that are applied to cases of namesquatting, obviously malicious packages (even if the author claims that it’s intended to be a demo), and so forth.

* PyPI has worked exceptionally hard (in my opinion) to minimize the potential disruption here: maintainers are being given free physical security keys, and those who can’t receive them will still be able to use TOTP. The rollout here has also not been enabled, and will not be for some time (to give maintainers plenty of time to enable 2FA on their own schedules); this is merely the announcement for the plan.

* Enabling 2FA on PyPI controls access to PyPI’s web interface, not publishing workflows. In other words: if you’re a maintainer of a critical project, enabling 2FA will not “gate” the releases you publish via CI. All of that will continue to work as it has before.

toxik• 4 years ago

Enabling 2FA on PyPI controls access to PyPI’s web interface, not publishing workflows.

Kinda feel like it should. (I also own packages that are critical.)

woodruffw9• 4 years ago

For publishing workflows, you should be using an API token (which only allows access to the upload endpoint and nothing else; critically, you can’t modify your account via an API token). This is consistent with how most other services handle both user and machine interaction, and (IMO) strikes the right balance between security and practicality.

yencabulator• 4 years ago

Great argument for avoiding centralized repositories.

Go import paths are just easier-to-type URLs.

operantoperator• 4 years ago

Congratulations: We Now Have Opinions on Your Open Source Contributions

The fallacy here is conflating package maintenance with OSS code authoring. Write code and throw it over the wall? Okay, why not? Package maintenance is another issue. Why wouldn’t people who depend on your packages have opinions on how you maintain them?

Maybe we can find a future for package indexes where maintainers of packages are not burdened further because the internet started depending on it. It's not the fault of the creator that their creation became popular.

Hopefully this is tongue in cheek. Or else it’s got some very Neil Peart energy.

Living in a fisheye lens

Caught in the camera eye

I have no heart to lie

I can’t pretend a stranger

Is a long-awaited friend

I’m a rockstar but I don’t want to be recognized at a 7/11 (or Tim Hortons).

bravetraveler• 4 years ago

This is a tricky one for me, and from what I can see... others too.

My initial reaction (and what I feel is common for others) was that this is overzealous -- 2FA is something everyone should already be doing.

It's somewhat like being upset that your poor hygiene came up while donating your time to the local soup kitchen. Your acts are good, but perhaps you shouldn't be handling/dispensing food.

I totally understand the fears of centralized power for these indexes. I think others (like myself) are just getting hung up on what lead to this consideration

There's something interesting with their picking and choosing of who gets policies, but in this case... it's fine in my opinion.

The most downloaded packages have the largest blast area, this might stop some explosions - so it's worth it [if you care about your users].

kibwen• 4 years ago

Armin, how much of the opposition to 2FA boils down to the "criticality" cutoff? Would you be less opposed to 2FA for publishing to these repos if everyone was subject to the same requirements? I say this because I like cargo-vet (and cargo-crev, etc.), but also I often feel like these package hosts should just have mandatory 2FA anyway as an extra level of security, but also it seems like there's quite a few people who are just opposed to 2FA in general and see it as burdensome.

nmstoker2• 4 years ago

I suspect level heads will prevail if it's discussed calmly, as for the most part it seems to be. There are legitimate concerns on both sides.

The thing that I'd be keen gauge is just how much work do people on both sides feel 2FA is here? Packaging has changed a fair bit over the years - does dealing with those changes represent more or less effort than dealing with 2FA? My gut feeling is that 2FA would be set up in a fraction of the time spent futzing about with adopting the latest packaging methods. Now obviously this isn't a completely fair equivalency - perhaps packaging is also part of the process that maintainers love (!) but for most people it feels like a necessary step rather than the aim of the game. If there's another thing to compare it with that's better, I'm all ears.

wyldfire• 4 years ago

One thing that wasn't discussed in this post was SOS [1]. While PYPI's definition may not match the SOS criteria for criticality, SOS does state "... even if your project doesn’t meet all the criteria, we still encourage you to apply and provide your own criticality justification."

Doing work to improve the OpenSSF scorecard [2] could result in the author (or others, for that matter) getting paid. It may not map one-to-one with 2FA but it might make it easier to swallow some of the requirements from PYPI. It makes sense for companies like Google to pay maintainers/curators to focus more on security.

[1] https://sos.dev/

[2] https://github.com/ossf/scorecard

akagusu• 4 years ago

As developers, I think we need to think about how we reach this situation where we rely so badly on 3rd party dependencies to do our jobs.

There was a time when all we need as a framework like Django or Rails to write our code on top of it with few 3rd party dependencies, usually something that we could copy to our own repo, read and verify the code and be happy.

Now, no matter what ecosystem you are, it could be Python, Javascript or something else, you end up with hundreds of dependencies even for trivial and basic apps.

How did this happen?

Maybe it is the time to rethinking what we have doing.

peteypao• 4 years ago

I am saddened by the author's take on 2FA. I am saddened that so many in this community share his POV.

Come on people! These Supply chain issues have real world consequences. Y'all act like this is some huge burden.

oxff• 4 years ago

This is only a surprise if you thought Open Source wasn't you slaving away for big tech.

Izkata• 4 years ago

There is a hypothetical future where the rules tighten. [..] Or the index wants to enable reclaiming of critical packages if the author does not respond or do bad things with the package.

This has already happened at least once on npm, and I think maybe a few times.

skyzyx• 4 years ago

To me this sounds like “I don’t want to do the thing that is obvious and sensible because I just don’t wanna.”

Personal liberty? Sure. But not when your personal liberty negatively impacts the rest of society. Just like how you’re not allowed to shout “fire“ in a movie theater because of the harm it could potentially cause. Your personal liberty ends where danger to others begins. If you don’t want to use 2FA on your Google account, knock yourself out. The context of Pypi is different.

Yes, everybody should be using 2FA. And we should also be looking into how to perform package signing and verification. Of course we should. This isn’t your grandfather’s Internet. These are table stakes in 2022.

I hope that there is a future where Pypi mandates those things because they’re good for everyone. They improve things for the entire ecosystem. I’m sick and tired of discovering that Python packages I depend on are being hacked or typo-squatted by malicious packages.

Oh, and get vaccinated — because it’s exactly the same premise. Stop being selfish.

Congratulations: We now have opinions on your open source contributions

Related Stories