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.
I think i would strongly disagree with this view - this is similar to arguing that people should just be able to release plans for nuclear weapons (or take your pick of less extreme examples) without adding responsibility to themselves, etc.
There's no obvious reason they should be able to, or that it is a net benefit to society. It's one of those things that people often think "sounds good", but isn't that great in practice, ever.
In fact, most of the problem that exists today in OSS security, support, etc is precisely because of people opening up code without trying to add any responsibility to themselves. At the same time, OSS has produced 100 of everything, so it's really hard to believe arguments that "if we didn't let this happen, things would not progress" and the like. I don't believe we would have been worse in terms of progress, etc, if we instead had 10 of everything, with the people more willing to take responsibility.
More practically, society has always believed in balance in every similar sort of thing, so it's not obvious to me why the extreme of "everyone can release anything without any responsibility" is ideal for anyone.
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.
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.
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.
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.
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.
Now that's fine under open source licenses -- but if you want the "free", you also have to take the "no warranty".