Hi, security here. We've tried, but the amount of people you need for this vs the amount of people you have trying to review and click the big button always means that this step will be a bottleneck. Thus this step will be eliminated.

A much better approach would be to pin the versions used and do intentional updates some time after release, say a sprint after.

▲

themafia 2 days ago | parent | next [-]

Why not just release escrow? If I try to push a new release version another developer or developers have to agree to that release. In larger projects you would expect the release to be coordinated or scheduled anyways. Effectively we're just moving "version pinning" or "version delay" one layer up the release chain.

▲

habinero 2 days ago | parent [-]

A lot of libraries are maintained by a single person.

▲

themafia 2 days ago | parent [-]

Are those the ones typically involved in supply chain attacks?

There are no perfect solutions; but, let's be reasonable.

▲

ArcHound 2 days ago | parent [-]

Actually, yes, they are the prime targets: https://en.wikipedia.org/wiki/Npm_left-pad_incident or seemingly https://en.wikipedia.org/wiki/XZ_Utils_backdoor as well.

	▲	themafia a day ago \| parent [-]
		xz has dozens of contributors and two active maintainers. It was the actual example I was thinking of. The code was submitted by a third party and not a result of a developer machine compromise. left pad wasn't a security incident. It was a capitalism incident.

▲

zbentley 2 days ago | parent | prev | next [-]

Pinning, escrowing, and trailing all help, but I'm not sure "this step will be eliminated" is inevitable.

Package manager ecosystems are highly centralized. npm.org could require MFA (or rate limit, or email verification, or whatever) and most packagers would gripe but go along with this. A minority would look for npm competitors that didn't have this requirement, and another minority would hack/automate MFA and remove the added security, but the majority of folks would benefit from a centralized requirement of this sort.

▲

ArcHound 2 days ago | parent [-]

Let me rephrase - manual security verification is a velocity blocker. People won't do manual security verification of changes.

I agree that npm.org requiring MFA is a good idea in general and in this case.

	▲	habinero 2 days ago \| parent [-]
		Yup. As someone who's been on both the eng and security side, you cannot improve security by blocking the product bus. You're just going to get run over. Your job is to find ways of managing risk that work with the realities of software development. And before anyone gets upset about that, every engineering discipline has these kind of risk tradeoffs. You can't build a bridge that'll last 5,000 years and costs half of our GDP, even though that's "safer". You build a bridge that balances usage, the environment, and good stewardship of taxpayer money.

▲

jmward01 2 days ago | parent | prev [-]

Yeah, I am looking at that on the use end. It sounds like on the python side this type of thing will be more standard (uv now and soon pip supported with version date requirements). I think time is a big missing element in many security in depth decisions. It can be time until you adopt like use no package newer than xx days or time it takes to deploy etc etc. Unfortunately the ecosystem is getting really diverse and that means ever more sophisticated attacks so we may need to do things that are annoying just to survive.

	▲	ArcHound 2 days ago \| parent [-]
		Yes, that's why I recommend intentional updates. Planning at least a sprint later gives you a week or two, hoping the community catches such issues.