[hombre_fatal]

Seems like a pointless, false sense of security.

What about all the attacks where the malicious actor is someone with publish rights, like friendly package takeover? Your proposal makes that even more effective since now the attacker gets a nice "published with mfa" badge.

[kpeekhn]

It would have prevented this attack, so I'm not sure how its pointless. Obviously it doesn't fix everything. MFA is MFA. I don't know why anyone would take it as a guarantee that some third-party has audited all the code.

[hedora]

I don’t see how it would have prevented this attack. It sounds like this was an old, semi-forgotten account (with a old password), so the attacker could have simply enabled 2FA, pushed the gems, and then disabled 2FA again.

[hombre_fatal]

> It would have prevented this attack

Your post was about a "published with mfa" vanity badge which I was responding to, not the merits of mfa in general.

[kpeekhn]

sorry, that is not what I mean.

I don't care really about a badge, I care about the information being available so that it can be used in Bundler. Its about developers being given the choice in their gemfile to disallow installation of any gems uploaded without 2FA. But in order to do that, we need rubygems to publish that information.

[hombre_fatal]

No, I understand you. My point is that whether a package uses 2FA or not should have zero impact on your security practices, yet your proposal suggests otherwise.

It doesn't seem like it does you much good to know if a package uses 2FA except to potentially weaken your defenses. For example, any scrutiny you level at a non-2FA package should also be leveled at 2FA-enabled packages. Though I suppose there is a non-zero benefit, so I won't belabor this argument any further.

Perhaps package repositories should be nagging publishers to enable 2FA. Though poorly implemented 2FA also introduces new attack vectors like the "lol lost my phone" social engineering attack.