[HN Gopher] Yes, I have opinions on your open source contributions
___________________________________________________________________
Yes, I have opinions on your open source contributions
Author : di
Score : 82 points
Date : 2022-07-11 20:33 UTC (2 hours ago)
(HTM) web link (www.b-list.org)
(TXT) w3m dump (www.b-list.org)
| dvt wrote:
| > So, look, I get that there are some people who want to live in
| a world built on caveat emptor and the idea that it's always and
| only your fault if something bad happens to you. I get that there
| are some people who think this is the only kind of world open
| source can be. Maybe Armin is one of those people, or maybe he
| just argues like one without realizing or intending it. [...] But
| no. Just... no. That would be a terrible world, and a terrible
| model for open source software.
|
| Is "that would be a terrible world" supposed to be a counter-
| argument? The world _is_ built on caveat emptor, especially when
| downloading random packages off the internet. That 's why
| browsers are sandboxed. That's why people run virtual machines.
| The vetting process for adding new dependencies at big
| corporations can literally last months. The 2FA nonsense does
| basically nothing in practice (vetting will not and _should not_
| magically go away), and only adds an undue burden on developers.
|
| The internet is a dark forest and I think it would do us a bit of
| good to treat it as such.
| woodruffw wrote:
| > The 2FA nonsense does basically nothing in practice (vetting
| will not and should not magically go away), and only adds an
| undue burden on developers.
|
| I don't understand this claim -- are you saying that 2FA adds
| no protection of value in the context of package
| maintainership, or that does nothing _in general_? I 'd like to
| understand the reasoning behind either, whichever it is.
|
| My 0.02c is that 2FA has empirically reduced the incidence of
| ATOs on major services, and eliminates entire systemic
| weaknesses in account systems (like ATO via password reset). It
| stands to reason (to me) that PyPI is a service like all
| others, and benefits similarly.
| sam0x17 wrote:
| > The 2FA nonsense does basically nothing in practice (vetting
| will not and should not magically go away), and only adds an
| undue burden on developers.
|
| This is true, but to play devil's advocate, how many HN
| articles have we seen where X critical NPM package had been
| compromised by a malicious user who gained control of the
| package maintainer's account? There are many examples of this.
| If a new package deployment system were to launch in 2022, I
| wouldn't be surprised if 2FA was required for all publicly
| listed packages, full stop, not just critical ones. Viewed
| through that lens, it really isn't that unreasonable.
|
| That said, I think full power should be in the hands of the
| developers who maintain these packages when it comes to the
| actual content of the packages. Package systems should not be
| editorializing. If the author of [insert major package here]
| wants to upgrade a version that replaces the whole package with
| a console animation of a turtle, that's his/her choice as a
| developer, and simply should be viewed as a "breaking change".
| Intervening in THOSE scenarios I view as completely out of
| control on the part of package ecosystems. Let people leverage
| their creations however they like. Your trust is supposed to be
| in the maintainer. If they aren't trustworthy, you shouldn't
| use their software in the first place. If they decide to go in
| a new, breaking direction, that's their decision. Caveat
| emptor.
|
| These scenarios though, are starkly different from scenarios
| where the package maintainer's own intent is subverted by a
| malicious hacker / user. That's a whole other can of worms, and
| I agree we need better controls to protect all packages from
| these types of scenarios.
| jka wrote:
| Odd but serious question: could there be ways to distribute
| versioned software that doesn't require management of
| developer accounts (and the associated time-and-effort costs
| related to account takeovers)?
| tsimionescu wrote:
| Not if the goal is to avoid vetting each new version as if
| it were a completely new dependency. The whole reason for
| the current system, and the very idea of new versions of
| "the same software", is that we want to be able to rely on
| the reputation of a project to make certain decisions. For
| example, we trust Linux 5.11.1 to be non-malicious and to
| be mostly stable etc largely on the reputation of the Linux
| project. We don't go around vetting the code of such s
| project except in efemer specific niches.
|
| If we don't trust the provenance of the code we're getting
| though, that reputation becomes irrelevant. As such, this
| is a problem of identity assurances and access management,
| it can't be solved otherwise.
| jka wrote:
| Ok: you've provided two requirements that I agree with:
|
| - It should be possible to compare between two releases
| (I'd personally like to see a code diff, ideally with a
| complete path of the commits involved)
|
| - Providing a reputation visibility mechanism (for
| publishers? author(s)?) across a series of releases is
| important
|
| Those don't require user accounts necessarily, though.
| And responding to the end of your message: identity
| assurances, yep, those seem necessary; access management,
| I'm not so sure.
| donaldstufft wrote:
| All major repositories editorialize to some extent, they
| would be awful if they did not.
|
| For instance, PyPI will take down your software if we
| determine it to be malicious in some way, which is extending
| editorial control over what's on PyPI.
|
| Generally speaking, though, PyPI does not concern itself with
| the contents of the packages shipped through it as long as
| they are reasonable packages. If a project wants to break
| compatibility, then that's on them. We strive to let projects
| manage themselves, in whatever way they think makes the most
| sense.
| bjt2n3904 wrote:
| > Some of this may just be due to incommensurable world-views. My
| view of the world is based on the idea that my actions may have
| consequences not only for me, but also for other people, and that
| I have some responsibility to at least consider those other
| people when deciding what actions I will take.
|
| Very well then. Do whatever you think is necessary and
| appropriate.
|
| For you. Don't heft your ideas on other people.
| yjftsjthsd-h wrote:
| Well, there's an easy solution to square these viewpoints. People
| who prefer a caveat emptor can keep operating like that, and
| people who want to be responsible can drop the "AS IS" clause
| from the license and put their money where their mouth is. (And
| really, none of this "well yeah the license says that but really
| you should be held to account for other stuff"; either commit or
| don't.)
| vore wrote:
| > If he doesn't owe us anything, then we also don't owe him
| anything. Perhaps he'd like to take back his code and the rest of
| the world can take back all the opportunities and other things
| he's been given In exchange.
|
| I feel like this is a rather silly take. Book-writing, speaking,
| etc opportunities are not ongoing burdens like open source
| maintainership. Even job opportunities you can choose to quit. I
| think ultimately if people are doing things for free you can't
| ask too much of them since they are well within their right to
| stop doing it for any capricious reason.
| skybrian wrote:
| Yeah, the second sentence isn't a great argument because it's a
| voluntary relationship, you can quit at any time, and that
| doesn't mean you have to give back any benefits you received.
|
| In particular, you can quit maintaining an open source package,
| or stop publishing it in an index and let someone fork it.
| (Maybe you feel a little guilty, but that seems like a feeling
| to get over if it's not working out for you.)
|
| But it still works both ways. If you're not finding it fun
| anymore, that doesn't say anything in itself about who, if
| anyone, is to blame.
| TimPC wrote:
| I feel like you're taking the author out of context. His point
| is that without the open-source work fewer opportunities would
| exist for the person doing it. So it's a bit disingenuous to
| act like you do all of this "purely for free" when it's more
| like "self-marketing". I get how imposing on people doing the
| former can be unreasonable, but asking things of people doing
| the later seems quite fair.
| ConstantVigil wrote:
| TimPC wrote:
| The original author seemed to think so and the regular
| speaking engagements and book deals seem consistent with
| that. It might not be the exclusive reason but it certainly
| seems a factor.
| pyrale wrote:
| There's a very simple way to make that opinion count, you can
| hire the maintainer.
|
| Open source has been built on an endless stream of people making
| personal sacrifices and often burning out. Seeing friends slowly
| getting devoured by anxiety crisis or burying themselves to
| support commercially used software, barely being thanked for what
| they give to the community, has been one of the most depressing
| parts of this industry.
|
| If you don't support that particular piece of infrastructure,
| your opinions on it are worth zero. Even if you're a well-known
| open source maintainer, and some times even more so. It is
| understandable that people getting a comfortable job thanks to
| their contribution on a high-profile project have a different
| view from people that don't, but that doesn't make it a better
| view.
|
| In retrospective, open source was bound to have these dynamics,
| with some people benefiting from their open-source work not
| seeing why people not paid to participate don't enjoy being told
| what to do. I wonder whether we'll see a friendlier environment
| in the future, or whether open-source will end up being a
| cooperative of companies sharing code among themselves.
| heavyset_go wrote:
| Agree with this, and you've put it better than I would've.
| ranger207 wrote:
| The article touches on an important point: the set of open-source
| developers includes PyPI maintainers. A related distinction is
| that yes development effort required matters, but so does
| operational effort required. By enforcing 2FA, PyPI reduces their
| support burden a bit by not having to deal with account
| takeovers, worrying about account takeovers, and responding to
| account takeovers. Yes, by mandating 2FA that increases the
| developer's effort, but by refusing to use 2FA that increases the
| operational effort of PyPI. There's probably a discussion to be
| had about how much can PyPI lower its level of effort by large
| amounts by imposing small increases in effort on developers, and
| whether those effort values are large or small or whatever, but
| in this particular case I'm inclined to support the small amount
| of developer effort required to massively reduce the operational
| effort of both PyPI and everyone responsible for vetting packages
| for use
| jka wrote:
| That's a very good point regarding operational cost of handling
| account takeovers.
|
| I'm not sure I have much useful commentary to add, but it does
| occur to me that a sufficiently-sized pool of software users
| could inspect changes (either at individual-commit-time and/or
| at tagged-release-time) regardless of whether each changeset is
| by the same author or in fact a different person every time.
| armchairhacker wrote:
| writing open-source doesn't mean people can't criticize you. It
| doesn't mean the places you publish your software can ask you to
| do stuff or they'll un-publish. It doesn't mean others can't
| republish them yourself.
|
| It _does_ mean you can ignore any and all criticism and do
| whatever you want. It does mean you can refuse to do what the
| package managers or community want. Even if your product has a
| glaring bug or security hole or is offensive! And you can put the
| burden of maintaining or patching your app to others.
|
| And that's fine, if you do so you're not a bad person. Because
| others can maintain and patch your app. You have absolutely no
| obligation to maintain or address any complaints about your open
| source software.
|
| But you do have to accept that people will make those demands and
| complaints. Not outright insults and hate speech, those are too
| far, but complaints about your software (even if harsh) are fine
| and expected. If they bother you, IMO the best thing to do is
| politely ask "please stop" and ignore them.
| ConstantVigil wrote:
| jka wrote:
| Choosing to use FOSS software to build products/services has
| always involved an element of caveat emptor, and even with the
| best of intentions, mistakes and errors are introduced sometimes,
| as they can be into commercial software.
|
| The technology industry (as the typical consumer of FOSS)
| generally understands that and introduces appropriate measures
| (dependency reviews, hiring developers with relevant experience,
| requesting professional security audits, keeping backups, ...).
|
| Despite all those (sometimes expensive) measures, industry
| continues to develop (and indeed thrive) using FOSS, implying the
| trade-off is worthwhile. My guess is that it is in fact
| _massively_ worthwhile, especially when comparing the technology
| economics of today with years and decades past.
|
| Therefore I think it's reasonable to ask questions any time that
| barriers are raised -- however small -- on the production-side of
| FOSS. That's not where the bulk of the revenues are accruing.
|
| (I also have a vague sense that 2FA could later be misused as an
| attempt to strongly-attribute blame, which again feels
| potentially unfair/unbalanced. if your business risk is high when
| upgrading packages, then you should review those updates more
| carefully and keep a record of the financial efforts and rewards)
| tsimionescu wrote:
| What does business have to do with PyPI? They are themselves a
| free project, for everyone using them.
| jka wrote:
| Offering an opinion: the tech industry is invested in the
| success of PyPI -- perhaps not always in a literal monetary
| sense, you're right, but certainly in an ecosystem sense.
| paganel wrote:
| With all due respect to James, without whom I probably wouldn't
| have my current job (I've been programming in Django since the
| 0.96 days, that is 16 years now), I think Armin is right on this
| one:
|
| > PyPI asks for 2FA today, what might they ask for tomorrow?
|
| Yes, slippery slopes are real because they happen, especially in
| this very tense and very non-rational geo-political climate. Yes,
| today it might just be "use 2FA with you still want to actively
| maintain your own package", tomorrow it might be "boo-hoo-hoo,
| you've followed/liked Putin/Xi/whoever the powers that be don't
| like, you're a threat to liberal democracy, we can't leave
| critical infrastructure in your hands, bye-bye", and there will
| be nothing for the package maintainer left to do at that point.
| kevinh wrote:
| How does mandating 2FA get them any closer to that second
| point? If they wanted to start with that, they could. They're
| two separate issues.
| bjt2n3904 wrote:
| The entirety of the last decade in open source software
| development can be summarized as this: it is morally
| reprehensible for your project to not support the causes du
| jour.
|
| You must adopt a COC. You must rename your branch from
| "master" to "main". You must use "inclusive" language in your
| documentation.
|
| Why? Because you must assume the responsibility for
| everything your project touches. A bad person uses your
| leftpad.js to perpetuate badness. You must stop them. Someone
| might get their feelings hurt. You must preemptively protect
| them.
|
| This is an impossible task. 2FA is fine, sure. I use it
| myself, and advocate for others to do so as well.
|
| But I'm sick and tired of the "harm reduction" mantra that
| means I have to entirely rewrite my documentation every 6
| months.
| kevinh wrote:
| If the last decade has been all about that, then clearly a
| 2FA mandate won't lead to it, since it's already here.
|
| FWIW, I have multiple open source projects. I don't have a
| COC. I haven't renamed any of my branches. I haven't gotten
| any pushback.
| elteto wrote:
| Dude, how did you go from 2FA for a Python package to Putin in
| a single sentence? This makes no sense.
|
| Look, publishing to PyPI is not a right. If typing 6 digits is
| too much burden you can drop a source tarball in some web page
| and call it a day, you don't have to go through PyPI. Done.
|
| I, for one, I'm very very glad that a piece of _critical
| infrastructure_ that I depend on is a bit more secure.
| paganel wrote:
| > Dude, how did you go from 2FA for a Python package to Putin
| in a single sentence? This makes no sense.
|
| The 2FA thingie is not implemented because of some random
| dude who might want to steal a bitcoin or two, is implemented
| against state actors. This being the US we're talking about
| (and the West more generally) the state actors taken into
| consideration are: China, Russia, Iran, probably North Korea
| (probably in this order). Hence my mention of China and
| Russia in my initial comment.
| _greim_ wrote:
| > PyPI asks for 2FA today, what might they ask for tomorrow?
|
| If and when they start policing political views of their
| maintainers, it would be fair to criticize them. But the
| theoretical possibility of such a thing happening has no
| relevance to whether 2FA is a reasonable request.
| paganel wrote:
| Are the 2FA dongles provided by Google available to
| maintainers that reside in countries the US (and the West
| generally) doesn't generally like? I'm thinking, explicitly,
| at China, Russia and Iran. Most probably no, even though I'd
| love to be proven wrong on this. As such, this is already a
| political thing.
| sleepybrett wrote:
| If they slip further down the slope you can, as a maintainer,
| protest there. 2FA is literally the least you can do to help
| prevent the kind of 'supply chain attacks' we've been seeing in
| the open source community for years now. If they continue, in
| spite of your protest, you can always distribute your library
| some other way or retire it.
| pyrale wrote:
| The author of the article this thread is about is litterally
| pushing further down that particular slope:
|
| > And if your package gets established and has people
| regularly using it, you have some responsibility not to mess
| with those users. If you want to make backwards-incompatible
| changes, for example, communicate them and bump the major
| version number. If you want to stop maintaining the package,
| post an announcement about it and be willing to hand over to
| someone else to continue work.
| mushufasa wrote:
| > And finally: if you're determined to take something I've said
| above, find the least charitable interpretation of it you can
| come up with, and argue with that, please know that I don't read
| Hacker News and haven't for years, so I won't see or respond to
| you.
|
| from the linked article, i'll just leave that here
| ConstantVigil wrote:
| khlpq wrote:
| protomyth wrote:
| With the belief that everyone is well intentioned and wants whats
| best for everyone, I think the thing that freaks me out about
| this whole thing is that through some process a developer has had
| their work declared 'critical'. If PyPI said this was a new
| requirement for everyone, then it would be make more sense, but
| the sudden declaration just seems problematic. I get there is a
| resource issue, but no one likes getting an e-mail that they're
| now subject to new rules not applied to others.
|
| So you maintain a package 'X', that has been determined to be
| 'critical'. It just seems like some user of package 'X' needs to
| perform some action to insure the group safety. It just seems
| like the one party that benefits the most isn't doing anything to
| help the situation. Thinking about it, what if the three users of
| your package are the credit agencies? The whole criteria seems a
| bit arbitrary.
|
| _But there's a reason why the slippery slope is a fallacy_
|
| Yeah, if anything, its a certainty not a fallacy.
| giaour wrote:
| The "critical" designation is not arbitrary. It's based on
| download statistics. From https://pypi.org/security-key-
| giveaway/:
|
| > What determines if a project is a critical project?
|
| > PyPI determines eligibility based on download counts derived
| from PyPI's public dataset of download statistics. Any project
| in the top 1% of downloads over the prior 6 months is
| designated as critical.
| protomyth wrote:
| Its still not a great measure. A project with three downloads
| that are all from the credit rating agencies, or a project
| with 100 downloads from all banks would be considered
| 'critical' by most folks.
| giaour wrote:
| But not by PyPI! Whoever is in charge of supply chain
| security at those credit rating agencies and banks should
| think long and hard about what they've gotten themselves
| into, though.
| protomyth wrote:
| I'm a bit unclear about your response. My contention is
| that the method of determination of critical is based on
| something that really doesn't tell you how critical it
| is. I do believe the customer has a responsibility but I
| am not seeing any of that in PyPI's actions.
|
| Do I blame or think PyPI did anything wrong? No. I think
| everyone has the best intentions. I just think
| arbitrarily declaring someone work 'critical' without
| some involvement from the users of that developer's work
| is going to cause problems and not actually solve the
| issue. PyPI doesn't really have access to the information
| needed to declare something critical.
| giaour wrote:
| What I meant by my reply is that PyPI is using "critical"
| as a label for packages that meet a specific criterion. I
| agree that "critical" as an English word can be rather
| vague, but it is not in this case.
|
| PyPI's interest here is in the integrity of accounts that
| can publish PyPI's most widely downloaded packages. If
| you believe based on the chosen label that in the future,
| PyPI will come in and expand the criteria for
| criticality, then I guess that's possible? But it's not
| what's happening now.
| samastur wrote:
| It's not arbitrarily because you've been told the
| criteria already. The problem you have is that you
| disagree with criteria which, well, not sure what to tell
| you except that there are no universal conditions
| everyone would agree to as clearly just demonstrated.
|
| PyPI maintainers selected their own, as they have every
| right to and they are not obviously stupid as they seem
| to be a reasonably good proxy for which packages would
| afflict most developers.
|
| Personally, as a developer who both publishes and uses
| packages from PyPI, I'd love to know who finds 2 minute
| 2FA set-up too burdensome (and if you save it in your
| password manager, that's all you'll every have to do) so
| I can avoid their packages. I have little faith in
| maintenance of packages for which a minimal one-time
| effort (per account, not even per package) is too big.
| protomyth wrote:
| _It 's not arbitrarily because you've been told the
| criteria already_
|
| It's arbitrary because it doesn't seem to correspond to
| what is 'critical'. It might be an ok proxy, but I'm not
| really convinced of that either. I once again say I think
| _everyone_ is being well intentioned, but I do not think
| they actually have enough information to build out a less
| than arbitrary criteria.
|
| _Personally, as a developer who both publishes and uses
| packages from PyPI, I 'd love to know who finds 2 minute
| 2FA set-up too burdensome (and if you save it in your
| password manager, that's all you'll every have to do) so
| I can avoid their packages. I have little faith in
| maintenance of packages for which a minimal one-time
| effort (per account, not even per package) is too big._
|
| If it is not burdensome, then they probably should of
| just required it from everyone going forward. It would
| have saved any debate as to singling out individuals for
| a higher maintenance demand.
| jph00 wrote:
| I keep seeing this claim that open source maintainers shouldn't
| be upset about a 3rd party mandating we increase our maintenance
| burden to follow their new rules, because it's all about
| responsibility.
|
| But I also see people claiming that it's not OK for the UK to
| require an increased maintenance burden for the same reason:
| https://news.ycombinator.com/item?id=32055756
|
| I think we need to accept that it's not a simple matter of
| responsibility. It's a question of how much maintenance burden is
| OK to mandate. The claim that open source maintainers should be
| fine with this increased burden because "responsibility" is not
| logically sound.
|
| Also, the idea that there's no problem, because OS maintainers
| can just remove their package from pypi, totally ignores the
| point that that would be a really bad outcome for everyone that
| uses that package. I this that's actually a pretty _big_ problem.
| tsimionescu wrote:
| > Also, the idea that there's no problem, because OS
| maintainers can just remove their package from pypi, totally
| ignores the point that that would be a really bad outcome for
| everyone that uses that package. I this that's actually a
| pretty big problem.
|
| Is definitely not as big a problem as someone taking over their
| account and publishing malware under their name is.
| jph00 wrote:
| Perhaps -- but not "definitely". It depends on what the
| frequency of each of those things is.
|
| So far IIUC the frequency of critical projects being removed
| from pypi is 1 (in the space of a few days - although it came
| back), and account takeover of critical projects for malware
| publishing is 0 (in the space of many years).
| olliej wrote:
| I don't understand why this is up for debate.
|
| The Atomicwrites maintainer/author has been using PyPIs servers
| and infrastructure to host and serve his project for free.
|
| PyPI have no responsibility to do that, and that maintainer has
| always been free to publish his project himself. Instead the
| Atomicwrites maintainer doesn't want to do that, what they want
| is to be able to exploit someone else's infrastructure, and they
| want free rein on that infrastructure despite, again not paying a
| cent for that infrastructure. There is a weird belief that PyPI
| is the side of this equation that is exploiting the maintainer -
| by requiring literally the bare minimum of modern security - and
| not the Atomicwrites author exploiting the PyPI infrastructure to
| host their project.
|
| Anyone arguing that PyPI is not allowed to make any demands of
| someone using their infrastructure, for free, because that is
| somehow unreasonable, is delusional. It's no different than
| having your own project, and someone push a PR, and you being
| _required_ to take the change - after all they gave it to you for
| free.
| ivraatiems wrote:
| > Anyone arguing that PyPI is not allowed to make any demands
| of someone using their infrastructure, for free, because that
| is somehow unreasonable, is delusional. It's no different than
| having your own project, and someone push a PR, and you being
| required to take the change - after all they gave it to you for
| free.
|
| He's not arguing they're not allowed. He admits they _are_
| allowed, but he doesn 't want them to do it. He thinks it's a
| bad idea.
|
| I don't agree with him, but I think you are misrepresenting his
| views here.
| olliej wrote:
| He was free to simply stop using their hosting service, but
| what he did was try to continue to use their hosting service
| without doing the bare minimum to protect that service.
|
| So I don't believe I am misrepresenting them, nor the people
| who have defended their actions. They have made it _very_
| clear that they believe PyPI should be forced to host every
| project whether they want to follow the rules or not.
| the_mitsuhiko wrote:
| > He was free to simply stop using their hosting service,
| but what he did was try to continue to use their hosting
| service without doing the bare minimum to protect that
| service.
|
| Who is "he"?
| clysm wrote:
| > More seriously: two-factor auth is such a reasonable bare-
| minimum and easy-to-do (from the account-holder end) thing for
| account security these days that the objections being raised make
| no sense to me.
|
| As a security engineer, this is the thing I don't get about
| dissenters. Any account I actually care about has 2FA on it.
|
| By today's security standards, NOT adding 2FA just means you
| don't really care about your project. Hand it over to someone
| else in that case.
| atoav wrote:
| Well it _depends_ , is the thing the second factor is meant to
| protect actually worthy of that level protection?
| elteto wrote:
| Well, they literally thought about this! It's only required
| for critical packages, for whatever definition of critical
| they have.
| omoikane wrote:
| Depends. Some websites insists on implementing 2FA in a poor
| way (e.g. installing dodgy custom apps on users' phones), so
| for accounts that users really care about, it might be the case
| that they would avoid these poor implementations to reduce
| attack surface.
|
| (I am sure it doesn't apply to PyPI, but I am just saying both
| site operators and users need to adopt best practices in terms
| of 2FA)
| jrockway wrote:
| I feel like some of the disconnect comes from being a mandate
| rather than a persuasive recommendation. Imagine that they
| included some sort of case study to make it less abstract:
|
| Company C uses database driver P. On 2020-01-02 they upgraded
| their app to the latest version. On 2020-01-04 they noticed that
| someone stole all their user data. Upon investigation, Package P
| had a version uploaded on 2019-12-24 that sends all user data to
| evil.example.com. The tooling to upgrade the package doesn't show
| diffs, so company C had no way to detect this malicious change.
| How did such a compromised version get uploaded? Looking at the
| audit logs, it appeared that there were 2398438 unsuccessful
| login attempts to package P author's account, before finally
| uploading the new patch release from the same IP. Company C lost
| 8 billion dollars as a result of this. If author A had used
| multi-factor authentication, then this wouldn't have happened,
| because it would have taken more login attempts than there are
| atoms in the Universe.
|
| Then the author can see "hey I can save the shareholders of some
| random corporation 8 billion dollars if I make it harder for
| myself to release software". That's a better incentive than
| "because I told you to".
|
| I know it sounds a bit disingenuous to say this is just for the
| shareholders of random corporations. I'm being a little snarky.
| It's also good for your reputation to not get hacked, and using
| 2FA to log in every time is probably less time overall than
| reacting to a single compromise. Imagine how many emails you're
| going to get. Big pain. I just think it's important to show
| authors the cost/benefit. 2FA is easy. Next time it might not be
| something that's as easy, though.
| [deleted]
| zmgsabst wrote:
| I have the feeling that's because it's a "best practice" and
| not a data-driven decision.
|
| Wouldn't they have led with, "we've witnessed X attempts and Y
| takeovers in the past year, so we're introducing new security
| measures aimed at..."
|
| To me, this seems like more frog-boiling authoritarianism "for
| our own good", like the COVID lockdowns, censorship, etc.
|
| I'm tired of technology forcing me to do things "for my own
| good" -- and I recommend against companies who engage in those
| policies.
|
| These are all the same arguments trotted out to justify Windows
| spyware and forced updates that routinely lag my computer for
| hours -- because Microsoft knows better than me how to use my
| desktop and isn't shy about pushing me out of the way to do so.
| tsimionescu wrote:
| Why are so many arguments acting like the maintainers of PyPI
| who imposed this change are not themselves open source
| developers whose time none of us, including those who publish
| their open source code on PyPI, pay for?
|
| PyPI asking for 2FA is in no way different from an open source
| project asking you to run their unit tests before submitting a
| PR. Sure, it puts a burden on you, the open source contributor,
| but it is balanced by removing a burden from the project
| maintainers.
| franciscop wrote:
| That leaves a strange taste in my mouth. I love writing open
| source for both me and other devs to use it and make their
| lives easier; I understand that big companies will also use it
| since that's one of the places where devs work, and since I
| make mostly tools or meta-tools ("dev solutions" and not
| "business solutions") I'm happy with this arrangement. When I
| do a more business-like solution, I tend not to publish it as
| open source and remain on my list of trying-to-monetize side
| projects.
|
| But if you quantify it like this, "this company saved 8 billion
| dollars out of some extra work on your side, here is a pat in
| the back because they'd never even consider give back a single
| cent or helping in any way" it feels a bit strange. I know it's
| on me, and I just learned this contradictory feeling so need to
| unravel/understand it, but you def got the opposite feeling
| from me as expected.
|
| Edit: you added the "I know it sounds a bit disingenuous to say
| this is just for the shareholders of random corporations."
| later, right? Which kinda reflects a bit of this feeling
| jrockway wrote:
| With no data, I'm assuming this is all business-driven.
| Nobody is compromising software supply chains to make your 3D
| printer print 8% slower for the lulz. They're doing it to
| hack companies and compromise user data. If open source was
| just hobbyists making stuff for hobbyists, it might not even
| require a login to update a package. With companies involved,
| they to reduce this risk, and this comes at the cost of
| people not involved with the company's business. I can see
| why authors get annoyed; they are being required to change
| their workflow for a use case that doesn't interest them.
| Being asked to do boring work for free is not a great
| solution to anything.
|
| Personally, I don't have a horse in this game. I always use
| 2FA when it's available. I have already made the necessary
| adjustments in my workflow. But I get why people are annoyed
| that they have to change something. Imagine that this was
| "we'll send you a check for $1000 if you enable 2FA on your
| account". Bet there would have been zero angry blog posts.
| [deleted]
| tsimionescu wrote:
| > Imagine that this was "we'll send you a check for $1000
| if you enable 2FA on your account". Bet there would have
| been zero angry blog posts.
|
| That is just entitlement on the part of some open source
| devs. PyPI is already providing a huge service for them: it
| is publishing their package free of charge. Furthermore, it
| is maintaining old versions, scanning others for
| vulnerabilities, replicating across the world, resolving
| dependencies etc. They have every right to ask anyone who
| is enjoying their completely free service to put in the
| minute amount of extra work required to set up 2FA.
|
| Of course, anyone is also free but to want to put in that
| work, and so they can stop delivering their package on
| PyPI. Absolutely your right as an open source maintainer,
| and you have no one to answer to if that breaks some
| builds.
| giaour wrote:
| > Nobody is compromising software supply chains to make
| your 3D printer print 8% slower for the lulz. They're doing
| it to hack companies and compromise user data.
|
| The high-profile NPM package compromises in recent years
| have mostly targeted hobbyists/been indifferent to who they
| were targeting. Crypto miner malware doesn't care what
| computer it's installed on.
| 3pt14159 wrote:
| Right, so this is why I keep harking on the fact that we need
| a non-billionaires OS license. People will say "oh, no,
| that's not real open source" but it sure is as open as their
| chequebook. I'm hand waving a bit here, but if you have a
| stakeholder that's worth a billion dollars you can pay a $1m
| per year for the OSS library you use.
|
| When I write open source software I'm not doing it for Bezos.
| I'm doing it for Heather down the street who is trying to get
| a cool little project off the ground and maybe pay some
| bills. I'm even writing it for Frank who runs a modest 20
| person dev shop and maybe contributes back a bit here or
| there where they find the warts.
|
| I'm not building it for the psychos that have lost all touch
| with humanity.
| jrockway wrote:
| That makes a lot of sense to me. I don't know if I do open
| source even for Heather down the street, I mostly do it for
| myself. "I made a thing, come look." "Come look" is not
| really an invitation for "we looked and we took it and can
| you do all these things for me for free". It's really a
| tradeoff between ego/reputation and time. It's possible
| that people can ask you for more of your time than you get
| returned in reputation. (Ask any artist who has made
| something "for the exposure." People will do it! But they'd
| rather be getting paid.)
| franciscop wrote:
| I just consider future me as just another developer, and
| it's way too often that I've had to read my own docs to
| see how I was supposed to do something and thanked past
| me. I do have a preference of who uses my software, but
| in no way encode it since I believe it's just no
| realistic: future me > other OSS devs > indie devs >
| general devs > small companies > large companies.
| MonkeyMalarky wrote:
| Art is a great analogy here because you don't get to have
| a say in the process when an artist is doing it for
| themselves. You can look and critique, but you don't get
| to have control. If you want that, you're welcome to
| commission a piece and pay for it.
| nemothekid wrote:
| I don't see why people should be persuaded at all. PyPi is a
| software distribution mechanism to millions of PC globally.
| PyPi is putting their footdown and saying we are going to do
| everything in power to prevent PyPi from being used as a global
| malware distribution system. That involves not only securing
| our software, but ensuring the people who have the capability
| to do damage are following appropriate security protocol.
|
| It's the _responsible_ thing to do. If a package gets
| compromised its _PyPi_ that has to do cleanup work. It 's like
| complaining that the government forces you to wear your
| seatbelt.
| pyrale wrote:
| > It's the responsible thing to do.
|
| Also, conveniently, it's the thing whose cost is not paid by
| the people deciding to enforce it.
|
| > If a package gets compromised its PyPi that has to do
| cleanup work.
|
| Yeah, that's the very essence of being a distribution tool.
| samastur wrote:
| What costs? You can stuff 2FA token generation in many
| password managers that run on the very computer on which
| you develop. It costs you exactly zero except a couple of
| minutes to set it up.
| pyrale wrote:
| > You can stuff 2FA token generation in many password
| managers that run on the very computer on which you
| develop.
|
| That's one of the reasons I believe 2FA is mostly
| security theater. That and people insisting they need
| their shitty app on my unsecured phone.
|
| It's not two-factor if all of it is running on the same
| hardware.
| jwilk wrote:
| Related:
|
| https://news.ycombinator.com/item?id=32037562 "Congratulations:
| We now have opinions on your open source contributions"
|
| https://news.ycombinator.com/item?id=32026624 "Atomicwrites' old
| versions have been purged from PyPI"
|
| https://news.ycombinator.com/item?id=32058053 "PyPI is rolling
| out 2FA for critical projects, giving away 4k security keys"
| adfm wrote:
| Seems a bit janky to only require 2FA from "critical projects"
| and not all projects. Why cut corners?
| xorcist wrote:
| The weird bit is that quality control is so completely out of
| the question that it's not even mentioned, but authentication
| is seen as more important than anything else. I wonder how
| accurate that threat model really is.
|
| I mean, node-ipc would have happened regardless of how many
| authentication factors were involved in uploading. And offers
| to buy ownership will keep coming. What happened to
| Sourceforge wasn't lack of security.
|
| Turns out those distribution people did more than just wrap
| software in other formats. Turns out that multi stakeholder
| thing had merit. Who would have thought?
| woodruffw wrote:
| Quality control isn't out of the question, per se: it's
| part of a different threat model. The goal behind 2FA is to
| limit the latent threat of account takeover attempts, which
| increases as packages' criticality does.
|
| Quality control belongs more closely to the "integrity"
| category of threats, which is much broader in scope than
| account takeover. It's something that we're thinking about
| as part of designing additional security schemes for PyPI;
| you can follow some of that work under the PEP 480 and PEP
| 458 umbrellas.
| woodruffw wrote:
| There are many weights involved; PyPI is trying to strike a
| balance between them.
|
| Among them:
|
| * Project installs follow a power law distribution: the top
| 1% of packages account for 99% of installations, and the
| remaining 99% account for roughly 1% of installations. In
| other words: prioritizing the security of the 1% of
| _packagers_ means prioritizing the 99% of _users_ who depend
| on those critical projects.
|
| * PyPI has tried really hard to make 2FA as effortless and
| non-invasive as possible: the current program includes giving
| away two free physical hardware tokens, as well as a long
| grace period to ensure that maintainers are not caught in a
| sudden lurch between their open source and professional
| obligations. Both of these don't work at scale: PyPI doesn't
| have the material resources to give every maintainer free
| hardware tokens, and the same packaging power law means that
| a large number of relatively inactive maintainers will be
| caught by any deadline that gets set.
|
| Ultimately, the goal is to maximize the number of users
| protected, maximize the _quality_ of protection, prevent
| package user disruption, and minimize maintainer disruption.
| The current scheme, in my view, does a good job at achieving
| all of these goals.
|
| FD: I worked on PyPI's 2FA implementation, but I do not
| represent PyPI and am not a maintainer.
___________________________________________________________________
(page generated 2022-07-11 23:02 UTC)