[HN Gopher] Congratulations: We now have opinions on your open s...
___________________________________________________________________
Congratulations: We now have opinions on your open source
contributions
Author : the_mitsuhiko
Score : 181 points
Date : 2022-07-09 17:48 UTC (5 hours ago)
(HTM) web link (lucumr.pocoo.org)
(TXT) w3m dump (lucumr.pocoo.org)
| petters wrote:
| They should just have required 2fa for everyone.
| TazeTSchnitzel wrote:
| Reminds me of https://news.ycombinator.com/item?id=27106448
| kazinator wrote:
| 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.
| yencabulator wrote:
| Great argument for avoiding centralized repositories.
|
| Go import paths are just easier-to-type URLs.
| xg15 wrote:
| > _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?
| greatgib wrote:
| 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.
| bbayles wrote:
| FWIW, I also maintain a "critical" package, and I'm happy that
| the index is requiring 2FA for it.
| jrockway wrote:
| 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.
| givemeethekeys wrote:
| 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
| operantoperator wrote:
| > 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).
| zbird wrote:
| 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.
| bastawhiz wrote:
| > 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?
| zbird wrote:
| 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.
| submeta wrote:
| Much ado about nothing.
| secondcoming wrote:
| I only just now realised that PyPI stands for Python Package
| Index.
| raverbashing wrote:
| 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 wrote:
| > 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.
| perrygeo wrote:
| 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 wrote:
| 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.
| simonw wrote:
| 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".
| crumpled wrote:
| 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?
| __alexs wrote:
| 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.
| franciscop wrote:
| 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.
| massysett wrote:
| 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.
| franciscop wrote:
| > Years ago software was just distributed...
|
| Well it's not years ago, in general most languages have
| been centralized around a single large index, which gives
| many advantages but also some disadvantages like seen here.
| This has been great so far since they've been benevolent,
| but in cases like npm (which I'm most familiar with) the
| non-profit Node Foundation joined the private company npm
| inc. giving it basically exclusive rights. Previous node
| and npm inc developers have tried to make alternatives, but
| unfortunately the reality is if you want to publish a JS
| package today and want anyone to use it, you _should_ use
| npm.
|
| > Maintaining an index is not free
|
| No, it's indeed probably very profitable when npm was sold
| to Microsoft, since the npm owners fought tooth and nail
| before to keep it private and not part of the Node
| Foundation.
| ctoth wrote:
| 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.
| staticassertion wrote:
| > 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.
| otikik wrote:
| 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.
| rogers12 wrote:
| 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.
| bravetraveler wrote:
| 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].
| creatonez wrote:
| 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.
| Tainnor wrote:
| 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.
| jka wrote:
| 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.
| ev1 wrote:
| 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.
| throwawaybutwhy wrote:
| 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'
| duskwuff wrote:
| 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.
| throwawaybutwhy wrote:
| Timeo Danaos et dona ferentes. All in all, bad optics and
| fishy offerings. TOTP is definitely OK.
| Tainnor wrote:
| Nobody is forcing anyone to use particular devices. Those are
| optional. Only 2FA itself is mandatory.
| echelon wrote:
| 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.
| Tainnor wrote:
| 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.
| cowtools wrote:
| 2FA is a major pain in my ass and it is the only reason why
| I am forced to own and use a "modern smartphone" which is
| essentially a corporatist surveillance device.
|
| If more organizations just allowed me to have custodianship
| over my own keys like GPG for example, I could choose my
| own level of security by using a GPG smartcard if I wanted
| to.
| eropple wrote:
| _> 2FA is a major pain in my ass and it is the only
| reason why I am forced to own and use a "modern
| smartphone" which is essentially a corporatist
| surveillance device._
|
| TOTP-compliant services happily accept codes generated
| from non-mobile devices. 1Password even includes it
| (which is a unification of factors I don't personally
| trust, so I don't use it, but it's there if it fits your
| own threat model). They can also run on Android, etc.
| devices that literally-not-figuratively never touch the
| Internet, if device separation is a concern for you.
|
| If your hangup is Duo or Okta or similar--well, there's
| always the choice not to work at places that necessitate
| them for 2FA.
|
| _> If more organizations just allowed me to have
| custodianship over my own keys like GPG for example, I
| could choose my own level of security by using a GPG
| smartcard if I wanted to._
|
| Even developers don't want to touch GPG. That's why they
| don't and a large part of why things like Git commit
| signing are (IME) so rare.
| ev1 wrote:
| I use Okta and it supports webauthn/fido just fine,
| seemingly by default, including touch id (or any standard
| USB key). If it does not, it's because your SSO
| administrator is intentionally turning it off.
|
| Okta does not have my phone number or an app installed. I
| do not ever want to be pushed an approval, because I
| don't know who or what triggered it. I only want to
| proactively authenticate.
| eropple wrote:
| Oh, hey, I totally didn't even think of that. Of course a
| Yubikey (or whatever) would work there, too. Looks like
| Duo will work with FIDO2, too.
| ev1 wrote:
| Yeah, pretty much. I explicitly _want_ 2FA with a real
| 2FA factor on all of my services and all of my machines,
| but my caveat is that it has to be in my custody -
| yubikey, totp (not ideal but I do hold an encrypted back
| up of my seeds that I physically refresh sometimes),
| fido2, smart card, etc.
|
| Push no. Push on a personal device even more no. SMS and
| phone absolutely FUCK NO for any reason.
| infogulch wrote:
| You can put TOTP 2FA keys on anything. A yubikey. An app
| on your computer. In your password manager. Hell, build
| your own device from parts:
| https://hackaday.com/2018/01/04/two-factor-
| authentication-wi... . If you're forced to use SMS-based
| 2FA, I can't give you anything but my condolences because
| SMS-2FA is stupid. But most 2FA systems work with the
| very flexible TOTP keys so I don't understand the
| complaints.
| echelon wrote:
| I'm less interested in 2FA than the decision that folks
| will lose access if they don't enable it.
|
| 2FA itself is moot.
| hartator wrote:
| 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.
| kevin_thibedeau wrote:
| 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.
| staticassertion wrote:
| 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 wrote:
| > 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.
| staticassertion wrote:
| 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.
| [deleted]
| raggi wrote:
| 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.
| dataangel wrote:
| 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.
| radus wrote:
| 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.
| woodruffw wrote:
| PyPI does not use SMS 2FA. It only supports WebAuthn (which
| is preferred) and TOTP.
|
| Source: I implemented PyPI's 2FA.
| DiggyJohnson wrote:
| Cheers. I love when this happens on HN.
|
| Hope these comments don't make you go crazy. It's always
| fun and frustrating to see an area you are extremely
| familiar with being discussed by those unfamiliar.
|
| fun in this comment thread.
| woodruffw wrote:
| I have a lot of sympathy for some of the frustration
| being expressed here: I do a lot of open source
| maintenance, and _any_ amount of change to my workflows
| drives me up the wall!
|
| That being said: the PyPI maintainers are _also_ in this
| community, _also_ doing largely thankless work to keep
| one of the world's biggest package indices healthy (and
| secure). Their motives are good, and (IMO) the rollout
| here walks the right line between imposition and changes
| that are necessary to match the prevailing winds in
| supply chain security.
| staticassertion wrote:
| Please keep up the excellent work, I'm very encouraged by
| what I'm seeing from PyPI.
| woodruffw wrote:
| Thanks for the kind words. Just to clarify (and avoid
| stolen valor): I worked on the 2FA implementation, but
| not the current critical project scheme or free key
| giveaway. That was all done by PyPI's maintainers (I'm
| just a contributor), and they're absolutely incredible
| and tireless in their commitment.
| ev1 wrote:
| PyPI is correct 2FA: TOTP, WebAuthn etc
| robotresearcher wrote:
| 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.
| staticassertion wrote:
| That's not the symmetrical position. PyPI demands nothing of
| anyone. It provides a free service with terms of use.
| Tainnor wrote:
| PyPI is not _demanding_ that OS devs publish their code on
| their platform.
| hoten wrote:
| Slippery slope nonsense. Use 2 factor. Jeez.
| pwdisswordfish0 wrote:
| The apostrophe use in this post is out of control.
| bjt2n3904 wrote:
| 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.
| rubyist5eva wrote:
| 2FA is not a big deal my god get over it. You don't owe anyone
| anything for open sources but package repositories don't owe you
| anything either. Host your own repository if you don't like it
| see how that works out for you.
| morelisp wrote:
| 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?
| bastawhiz wrote:
| For all the heartache in open source right now, taking a hardcore
| stance against MFA is a weird hill to die on
| hgs3 wrote:
| 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 wrote:
| Once you start accepting payment for something, more
| responsibilities are implied.
| BiteCode_dev wrote:
| 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.
| nibbleshifter wrote:
| > 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.
| BiteCode_dev wrote:
| We used to say that about https, and now we got letsencrypt.
| dlor wrote:
| We've been working with PyPI to help integrate Sigstore,
| which makes signing (and verification) easier!
|
| sigstore.dev
| Tainnor wrote:
| What, exactly, is hard about signing?
| cowtools wrote:
| 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_dev wrote:
| In this particular case, Pypi is giving away hardware
| security key.
|
| I have 3 of them, it is secure and convenient.
| BiteCode_dev wrote:
| With root certificates, gov already have complete ability to
| MITM your https connection.
| woodruffw wrote:
| 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 wrote:
| > 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.)
| woodruffw wrote:
| 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.
| belfalas wrote:
| 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).
| [deleted]
| __alexs wrote:
| 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.
| colechristensen wrote:
| 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.
| ctoth wrote:
| 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 wrote:
| 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).
| josephcsible wrote:
| 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".
| Groxx wrote:
| 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.
| __s wrote:
| 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
| cowtools wrote:
| >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.
| striking wrote:
| You appear to have a fundamental misunderstanding of the
| 2FA in this case. TOTP-based 2FA is available for PyPI, for
| which any number of FOSS freely-runnable clients are
| available. See also https://pypi.org/help/#totp
| josephcsible wrote:
| I think GP is actually saying that there's no way to
| prove that users aren't storing their TOTP secrets in a
| way that defeats the purpose of 2FA, such as right next
| to their passwords in cleartext.
| the_mitsuhiko wrote:
| 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.
| __s wrote:
| Overall I agree that the matter is more nuanced than my
| original comment would indicate
|
| re requiring 2FA across the platform, I wouldn't be
| surprised if 2FA requirements eventually expand to everyone
|
| Maybe this could've been opt-in by having a way for
| projects to require their dependencies be 2FA all the way
| down. Since the current policy has a bit of a hole: if
| you're a critical package, are you allowed to depend on a
| non-critical package? Are you no longer able to add non-
| critical dependencies?
| jka wrote:
| 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."
| jka wrote:
| 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 wrote:
| 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/
| hprotagonist wrote:
| Or you could be this idiot, who had a snit and broke a bunch of
| CI yesterday: https://news.ycombinator.com/item?id=32026624
| smegsicle wrote:
| how embarrassing to have such a janky CI pipeline!
| Groxx wrote:
| "X wanted me to do Y, which I don't want to do and
| unambiguously have no obligation to do. I did Z out of
| curiosity. It broke more things than intended, so I fixed
| them."
|
| That hardly sounds like a snit.
| infogulch wrote:
| Published packages should be immutable. Sure, "unpublish" so
| it's no longer listed. Even display scary messages in your
| package manager's stdout. But once you publish a package, any
| package manager with the hash of the package contents in its
| lockfile should be able to continue retrieving it indefinitely.
| The fact that it's possible for any maintainer to break all
| consumers of their previously published works on a whim is
| insane to me.
| emu wrote:
| If pypi didn't enforce size limits, I'd agree with you. We
| routinely have to delete older versions of our package to
| make space for newer versions.
| throwawaybutwhy wrote:
| A thousand times this. Immutability, reproducibility,
| traceability.
|
| What irks one the most is the arbitrary discrimination
| between 'critical' and 'non-critical' maintainers. Use TOTP
| for everybody and be done with it.
| frenet wrote:
| 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.
| tonnydourado wrote:
| 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.
| DannyBee wrote:
| 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.
| brabel wrote:
| 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.
| staticassertion wrote:
| > 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.
| bastawhiz wrote:
| > 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 wrote:
| 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.
| the_mitsuhiko wrote:
| 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.
| [deleted]
| dataflow wrote:
| 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.
| TAForObvReasons wrote:
| 2FA attempts to assert "the person who is publishing the
| package to the registry is someone that the registry
| expects"
|
| As a user installing from a registry, you are trusting both
| the publisher AND the distributor.
|
| Consider an attack where the distributor is adding
| malicious code to 1% of installs. The publisher is not
| involved in the process and (unless code signing is
| involved) has no influence.
|
| But if code signing is involved, why is 2FA even needed?
| The signatures themselves should be sufficient proof.
|
| So 2FA overall is a solution in the lens that the
| distributor intermediates the relationship. This need not
| happen. People can chuck tarballs and post signatures,
| establishing more direct trust compared to the indirect
| solution.
| woodruffw wrote:
| > 2FA attempts to assert "the person who is publishing
| the package to the registry is someone that the registry
| expects"
|
| This is not what 2FA asserts in the context of PyPI. It's
| used solely for logins to the web frontend, which is
| where users can manage their projects and the permissions
| associated with those projects. The idea is to make
| account takeover more difficult, since that's
| (frequently) the first step in malicious package
| takeover. Assuming that you're using API tokens to
| publish to PyPI (which you absolutely should be), having
| 2FA enabled on your account will not affect any ordinary
| publishing workflows.
|
| We have separate plans to improve PyPI's support for code
| signing.
| staticassertion wrote:
| They solve different problems. Given a signed package I
| can say "this is signed by that key". I can't say how
| that key was registered, or who registered it, etc. 2FA
| would be where that key registration actually happens.
| dataflow wrote:
| That's not even the point of the blog post to begin
| debating it here. If the the author believes that then he
| can write a blog post about how 2FA is bad. That's not
| what we have here though. In fact, he instead says "it's
| a sensible thing" and his complaint is that it's a
| slippery slope: "More importantly though is what could
| come next. There is a hypothetical future where the rules
| tighten."
| frenet wrote:
| Fundamentally I agree with you. But I also think it easy to
| get the idea that "no responsibility" is a prevailing view.
| Or at least that it has to be. There are plenty of people
| who want to do their best. I would certainly considered the
| author's software involvement to be part of that. It is
| just hard to do. And increasing hard not only because of
| software but society at large (like job and housing
| markets). So the problem exists regardless of various
| positions on the issue.
|
| Or put another way. If we want open source developers who
| favor responsibility we have to make it easy for those
| developers. Otherwise we only end up with people who are
| fine with throwing things over the wall.
| jnovek wrote:
| When we write software as part of a job, we have all kinds
| of staff who support the project --- project managers,
| product managers, QA, marketing and sales, security etc
| etc.
|
| It really seems that, for open source projects, the author
| is expected to be responsible for everything.
|
| I think it would be a great benefit to all of us if people
| who wanted to open up code but didn't want to add
| responsibility to their own world felt welcome to do so. I
| think it's a problem worth solving.
| saagarjha wrote:
| What's interesting is that we don't really have this kind
| of structure in place elsewhere to my knowledge, outside
| of open source software. There's a limit to how much
| legal liability you can shed, and even after that social
| liability is much more fickle.
| dataflow wrote:
| > What's interesting is that we don't really have this
| kind of structure in place elsewhere to my knowledge,
| outside of open source software.
|
| https://developer.apple.com/support/authentication/ ?
| saagarjha wrote:
| Not for 2FA, for absolving yourself of all
| responsibility.
| the_mitsuhiko wrote:
| It's the free (no payment) part that makes the difference
| and outside of the Open Source movement many things are
| not provided free of charge because of the associated
| costs.
|
| Similar things happen for research papers or generally
| scientific content though. You won't be successful in
| suing an author of a study for incorrect content either.
| dataflow wrote:
| > It really seems that, for open source projects, the
| author is expected to be responsible for everything.
|
| If you wrote "for underfunded projects" I would agree
| with you. It's a pretty universal fact of life regardless
| of the nature of the source.
|
| > I think it's a problem worth solving.
|
| Definitely, I don't think anyone is against a solution to
| this problem. The question is what we can expect before
| the envisioned solution is finally created by someone and
| provided to us.
| CJefferson wrote:
| That doesn't seem to apply to companies -- they make
| billions from open source and give back little, or nothing,
| to the majority of the authous and packages whose work they
| build on.
|
| Now that's fine under open source licenses -- but if you
| want the "free", you also have to take the "no warranty".
| Tainnor wrote:
| 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.
| Brian_K_White wrote:
| There is no reason the index can't do the extra thing they
| want for their own reasons themselves.
|
| There is no valid reason to demand the already-a-volunteer
| do anything extra to supply something they want for their
| own reasons.
|
| They could collect the source and vet the updates all kinds
| of other ways than demanding the author jump through hoops
| for them, for free.
| staticassertion wrote:
| > They could collect the source and vet the updates all
| kinds of other ways than demanding the author jump
| through hoops for them, for free.
|
| At minimum it's completely unproven that that would be
| practical, whereas 2FA is trivial and has been widely
| deployed for decades.
|
| But if you feel strongly about this feel free to make a
| formal proposal. There are some nascent projects
| exploring this area that you could draw inspiration from
| and I'd certainly welcome tooling in that area.
| Brian_K_White wrote:
| What a weird leap. Now not only the author of some
| software has to jump through someone else's hoops, I a
| total bystander also has to? It does not require "feel
| strongly" to observe the invalidity of some argument.
|
| Rather, if you feel so strongly that something should be
| done, like vet that software, you could do it.
| staticassertion wrote:
| You don't have to do anything?
| the_mitsuhiko wrote:
| > But I would suggest to developers that if their
| contribution becomes "critical" and they don't want to bear
| that burden anymore, they should lose the rights to make
| any further updates, which is, I believe, also the line
| that PyPI itself takes.
|
| That seems worse to me for quite a few cases that go
| towards actual burden beyond 2FA. That implies the index
| will take away someone's permission over their creation as
| a result of too many other people also started using it.
| There is a reason why I have a "No Warrenty" clause in the
| licenses of my Open Source work. I have created it for
| others to enjoy it, but I reserve the rights to not be
| burdened by my users for the unpaid labor.
| hiphacker123 wrote:
| Caveat: Not everyone in FOSS is American, but...
|
| Here in the US folks tend to have some amount of burden
| on their creations, tools they use, etc. Just because you
| put out a sign that says "Not My Problem" doesn't make it
| so.
|
| Great example is these big gravel trucks hauling rocks to
| job sites, they'll rain stones on the roadway and the
| cars and sometimes pedestrians because the workers are
| sometimes too careless to pull down the tarp to secure
| their load. They'll put up a sign saying "DRIVER NOT
| RESPONSIBLE FOR DAMAGE" but the problem is they 100% are
| both legally and morally responsible.
|
| We also have some rules around nuisance, enticement, etc.
| For instance, if I have a pool and a kid jumps my meager
| fence and drowns I might we'll still be responsible, at
| least legally, because I put up an enticing thing but
| failed to consider how idiots might misuse it.
|
| To me, the pool one starts to get at or near "South of
| Sanity" but that's from where this mentality applies.
|
| Often you'll get some Node project some cool tech person
| shits out, pimps out to social media , then abandons when
| the real work comes out. Folks will pick it up early on
| as traction builds, then be stuck with abandonware when
| the author gets a new job or chases a different shiny
| ball. I would argue you at least owe a caveat in the
| README about your level of commitment to the project, a
| bit beyond a mere "not my problem" license line.
| massysett wrote:
| Wow. This attitude is exactly why I don't post software
| anymore.
|
| I'm not delusional; I know that the world might be better
| off without my creations littering it. But if I were an
| attorney advising $Bigcorp, messages just like this one
| are why I would advise against posting any free software
| unless there is a business case for how the benefit
| outweighs the risk.
|
| And a disclaimer does not eliminate risk, not even the
| heightened disclaimer you suggest (why isn't the
| disclaimer in the license enough?) The instant I have to
| defend a lawsuit, I've lost. It doesn't matter if the
| suit is meritless and I "win." Then instant someone sues
| me, the only winner is my lawyer.
|
| I guess this was all inevitable when people started
| relying on free software. They somehow think people who
| have given them something for free owe them something. I
| guess this works fine when the giver is $Bigcorp doing it
| for profit-seeking reasons. But this attitude is going to
| strangle the old small-time hobbyists who really were
| just scratching an itch.
|
| Now I know why some software is posted under pseudonyms.
| the_mitsuhiko wrote:
| You are absolutely right here. If anything the excluding
| of implied warranty works better in the US than many
| other countries for Open Source as typically a price is
| required for implied warranties to exist but even there
| are limitations.
|
| I also tend to agree that there is a certain level of
| added burden that comes with popularity that you cannot
| get rid of. This starts from the basic fact that I
| noticed a few years back of becoming a target of social
| engineering.
|
| I do however think for as long as we believe Open Source
| is a good thing and there is limited ways for developers
| to receive monetary compensation for their work, we
| should be quite careful here. Enrolling people into
| things purely based on the popularity of their creation
| without compensation to me feels problematic.
| radus wrote:
| I think it would be ideal if the increase in
| responsibility was accompanied by some actual reward, so
| the "congratulations" would be more genuine. I don't know
| what kind of reward would make sense - money makes sense,
| but who's money? Maybe you get a voice in the development
| and direction of the language and ecosystem? That would
| also constitute more responsibility but it might feel
| less burdensome and give you a seat at the table for the
| next such decision.
| giaour wrote:
| > That implies the index will take away someone's
| permission over their creation as a result of too many
| other people also started using it.
|
| The creation here is the package, not the distribution
| channel. You can use an alternative Pypi-compatible index
| (there's one built into Github, and enterprisey ones can
| be purchased from Azure or AWS) or you can put
| instructions for a local build & install on your blog.
|
| The maintainers of PyPI should be able to enforce some
| amount of quality control over _their_ creation, after
| all.
| Tainnor wrote:
| No, they simply take away your rights to publish your
| creation to _their index_.
|
| You can always publish your creation on your website or
| wherever.
| jka wrote:
| > You can always publish your creation on your website or
| wherever.
|
| What you're suggesting wouldn't solve the problem for
| critical packages, though; the effect would be similar to
| yesterday's package unpublish issue[1] (all users of the
| package would have to update their dependency references
| despite no change in the content of the code).
|
| [1] - https://news.ycombinator.com/item?id=32026624
| staticassertion wrote:
| So what? Users can do that if the maintainer chooses to
| move hosting.
| jka wrote:
| Sure, accepted. That'd be a disruptive change, though,
| and I think that a better approach is possible.
|
| The suggestion regarding separation of (immutable)
| packages and policy in the article could provide some
| hints in that direction.
| Tainnor wrote:
| No, the issue yesterday is that people had to go in
| manually to fix their CI builds, etc. That's simply not
| necessary if you don't update the version and yanking is
| disallowed (which it should be).
|
| After that, if people want to at some point update to a
| newer version of the package, yes, they will have to
| adjust.
| jka wrote:
| Hrm, fair point. Although migrating 'backwards-
| compatibly' like that could leave a lot of people in the
| cold if-and-when a security update for the package is
| released (and we're talking about critical packages here,
| at least for now).
| phlakaton wrote:
| How about you 1) leave old versions in place on the
| package index, 2) declare that you will not be providing
| further updates to the package through the index because
| of this issue, 3) go publish your stuff on your website
| or an alternate package index?
| frenet wrote:
| Sure, but then who does the work? No one is an answer but
| not much of a solution since the problem still exists.
| Index or package maintainers could do the work but would
| often also be unpaid and burdened even more. An
| organization could do the work but most packages don't
| reach the level where they would get adopted.
|
| If being unpaid is the problem then the most obvious
| solution is to charge for the index, possibly only for
| commercial use, like a streaming service. Use some for
| the index and give the rest to the projects who does the
| work. As far as I know it wouldn't be against open source
| as people think non-commercial licenses are. But it would
| still be hard to do for various reasons. Some legitimate
| and some not.
| jnovek wrote:
| 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?
| hoffs wrote:
| The amount of work required to maintain a very popular
| package is obviously higher, even without taking into
| account any distribution part. From your message it sounds
| like you expect same amount of work. Besides, the extra
| work from this side would pale to the extra amount of work
| needed to maintain just due to increase of users.
| liuliu wrote:
| Yes, that's the status-quo. But OP is arguing, rightfully
| so, that we don't want to put additional responsibilities
| to already hand-full maintainers. If anything, we want to
| reduce that to make open source community more
| sustainable. We've seen too much that maintainers burnt
| out, shutdown repos, or beg for money to just keep the
| light on. Once they turned the project into commercial
| endeavor to "spread" the burden, then they have the
| dilemma of "open-core" dual license.
|
| There must be a way to make the extra work minimal for
| maintainers even if their works are popular. For example,
| in the days people use apt / yum for distribution, both
| vetting and packaging are the responsibilities of the
| packagers, not the maintainers. (Not saying that's good,
| but just an alternative perspective, there is a reason
| why language-specific package registry wins today).
| dataflow wrote:
| > EDIT: to respond to the reply below, I realize that the
| amount of effort scales with the popularity of the project,
| but nobody joins the basketball team to warm the bench, you
| know? Why would I join a system where the definition of
| success is unpleasant to me?
|
| I'm pretty sure {your favorite popular basketball player}'s
| career prospects would not have been impacted by an NBA
| requirement to "spend 10 seconds sitting on the bench to
| warm it every day before playing". Doubly so if there was a
| reasonable argument that it would somehow make the stadium
| safer for their fans.
| jltsiren wrote:
| Volunteering is all about taking responsibility. If you
| contribute regularly to a project with many users, you
| can't avoid the responsibility. If you only want to express
| yourself by writing code without the burden of
| responsibility, you should contribute to something else.
|
| One thing I've learned from various volunteer projects and
| organizations is that good volunteer administrators are
| rare. Finding good people for the creative parts of the
| project is not particularly difficult, because creative
| work is inherently satisfying. Administrators are another
| story. Many try the job and quit, because they don't enjoy
| it enough to do it in their free time. Others are not
| suitable for the role. Some are good and motivated
| administrators, but they drive other volunteers away by
| trying to manage them. And then there are the rare ones who
| can be administrators and enjoy it without ruining the
| project for everyone else. If you manage to find one, the
| last thing you want to do is increasing their burden.
|
| As far as I understand, PyPI is largely a volunteer
| project. It works only because some people find running
| that kind of bureaucracy satisfying. It's their project,
| and they can run it any way they want. If their burden gets
| too heavy, they may quit, and then the project may fail.
| That would probably be a bigger issue than some open source
| contributors not liking how PyPI is run.
| mtrycz2 wrote:
| I find it bizarre that they don't ask for 2FA for all
| contributions. Possibly a historical inheritance?
|
| Edit: I now understand that they require a _physical_ device
| instead of a TOTP app. Yeah, that 's the line between
| reasonable and wtf.
| lopuhin wrote:
| > they require a physical device instead of a TOTP app.
| Yeah, that's the line between reasonable and wtf.
|
| No, a TOTP app is also allowed.
| mtrycz2 wrote:
| Well then, that's perfectly reasonable.
| staticassertion wrote:
| To tack on, they're actually giving away those tokens for
| free for those who request one.
|
| https://pypi.org/security-key-giveaway
|
| They're being beyond reasonable. This is outright _kind_.
| Tainnor wrote:
| > Edit: I now understand that they require a physical
| device instead of a TOTP app. Yeah, that's the line between
| reasonable and wtf.
|
| They don't.
| btown wrote:
| 2FA, whether TOTP or physical, comes with a per-user
| support burden for any organization that enforces it,
| because there must be a human-in-the-loop mechanism to
| handle "my 2FA devices were all destroyed/stolen, and
| others depend on me having access to my account." PyPI
| isn't exempt from this, despite mitigating with multiple
| 2FA devices, and says as much in the announcement
| https://pypi.org/security-key-giveaway/ -
|
| > Without multiple 2FA options, effect of losing a 2FA
| method results in the need to fully recover an account,
| which is burdensome and time-consuming both for maintainers
| and PyPI administrators. Enabling multiple 2FA methods
| reduces the potential disruption if one is lost.
|
| So there's a huge practical difference to PyPI of enforcing
| 2FA for all vs. enforcing for <1% of projects. I don't envy
| their position, and it's a reasonable compromise IMO.
|
| That said, it's absurd that PyPI didn't make more clear in
| the announcement linked above that TOTP apps are allowed.
| There's literally not an FAQ about the most important FAQ.
| They very well could have avoided the reaction from OP, and
| this entire debacle, with more thoughtful messaging.
| hanselot wrote:
| Is the whole point of this not to ensure that someone can't
| use your identity to produce a compromised package?
|
| When I download someone else's code its my job to make sure
| the code I run isn't riddled with spyware. Hence why I design
| my projects to rely minimally on external dependencies.
|
| Why should this burden be placed on the developer and not the
| user?
|
| If I buy a chainsaw and cut my arm off, is this the fault of
| the chainsaw manufacturer?
| burnished wrote:
| You do know that bladed machinery is made with more and
| more safety features right? No one actually thinks "oh fuck
| em if they lose an arm". It just isn't a good comparison,
| nor a good solution.
| dlor wrote:
| 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.
| x86x87 wrote:
| 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_White wrote:
| 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.
| [deleted]
| rrdharan wrote:
| 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").
| Brian_K_White wrote:
| So what? Too bad? No one else's problem? The reasons they
| want things vetted and attested was never contested. The
| fact it's a lot of work, is a given. And neither of those
| things explain why the author has to do it, necessarily.
| Maybe it's natural, maybe the author of a thing is
| generally the best positioned to attest and support their
| own output, but so what?
|
| If they find the software valuable enough that it matters
| that it's verified and certified, and the supplier doesn't
| feel like doing it, they could do it themselves or arrange
| for others to to do it or delist the filthy uncertified
| package or just tag it as not certified. There are all
| kinds of options besides demanding a volunteer do something
| they didn't aldeady feel like doing voluntarily.
|
| I don't get why everyone confuses the obligations here.
| Just because pypy wants something, no matter how
| understandable the reasons, doesn't change the fact that
| it's pypy who wants it, for their own reasons.
|
| The author derives no value from it (not neccessarily, they
| may choose to value the credit and exposure of their work
| appearing in the index, but they also may not). Pypy
| derives value from it, and all of the users derive value
| from it.
|
| The obligation for supplying that extra frosting they want
| on the cake lies with those who want it.
| staticassertion wrote:
| 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.
| Brian_K_White wrote:
| Invalid analogy, and the attempt to frame it that way is
| curious in the what-an-ugly-insect kind of way.
| staticassertion wrote:
| OK, I'll skip the obvious analogy. PyPI is a _free, open
| source service_. It hosts packages _for distribution_.
| When you go to PyPI you say "Hi, I would like to
| distribute software, can you do this?" and they say "Yes,
| you can do this for free. There's some terms of use, and
| we require 2FA."
|
| You can say "Great, I accept all of that, thanks for
| providing distribution of my code _for no monetary cost
| to me_ " or you can say "Ah, ok, thanks anyways but I
| would prefer not to accept that".
|
| Is that clearer?
| the_mitsuhiko wrote:
| The more correct analogy of what it looks like in a few
| months is PyPI coming back to you after a while saying
| "this package we are hosting for free you can only update
| or delete if you now follow these new terms if use. If
| you don't agree we take away your access but retain the
| package."
| staticassertion wrote:
| You can't say that's more correct. That's a prediction
| about the future that's based on nothing, as far as I can
| tell. Does PyPI have a history of increasing, unwelcome
| restrictions?
|
| I mean, of course you have to continuously accept terms
| of use changes as you publish to them. That is the same
| as anything else. To tack on a bit of additional
| conversation,
|
| "Hi, I previously published v 0.1, I would now like to
| publish v 0.2"
|
| "OK, cool, we have a new EULA if you want to publish 0.2"
|
| "Great, no problem, signed and now I'll publish" / "Ah, I
| don't like those new terms, I'll publish elsewhere or not
| publish at all"
|
| I don't get the complication here.
| the_mitsuhiko wrote:
| > You can't say that's more correct. That's a prediction
| about the future that's based on nothing, as far as I can
| tell.
|
| The statement I made is based on what is currently
| communicated. The "terms" is purely "you need to use 2FA"
| (which just to be clear I already said I have no quarrels
| with). I cannot judge what will be the future
| requirements will be for critical packages. Donald Stufft
| from PyPI on Twitter said that he could imagine requiring
| signed releases
| (https://twitter.com/dstufft/status/1545503252871004161).
|
| > I don't get the complication here.
|
| Maybe there is none, maybe there is. The consequence
| however undoubtedly is that if you do not accept the
| terms you lose access to your package on PyPI.
| staticassertion wrote:
| > Maybe there is none, maybe there is. The consequence
| however undoubtedly is that if you do not accept the
| terms you lose access to your package on PyPI.
|
| Right but I just don't get why this is notable or why
| anyone would ever be surprised by this, or why this would
| ever be controversial. I just can not wrap my head around
| this being framed as a complex issue when it seems so
| very straightforward.
| Brian_K_White wrote:
| It is indeed so very straighforward and not a complex
| issue, which begs the question why you might not be able
| to wrap your head around it. I call volition.
| perrygeo wrote:
| > 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.
| krab wrote:
| 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.
___________________________________________________________________
(page generated 2022-07-09 23:00 UTC)