Expose user's MFA status

[thepwagner]

Is your feature request related to a problem?

I'd like to know which of my dependency's owners have MFA enabled, so I can quantify the risk of a supply chain compromise.

Describe the solution you'd like

I'd like the Owners API endpoints to expose the status of the User.mfa_level enum for each owner.

I'd like this to be something users must opt in to (e.g. show_mfa: true): so the feature can't enumerate "weaker" accounts without MFA, only reassurance of accounts with MFA enabled.

Describe alternatives you've considered

I could fork/proxy all dependencies to control their release process, but that would slow collaboration/updates.

I could rely on Gem Signing to strongly authenticate Gem owners, but I expect MFA has a higher adoption rate and lower barrier to entry. Similarly I could wait for rubygems-trust or TUF 🤞.

Additional context

This is minimal "you can trust me" evidence: not that the gem isn't malicious, but that some care went into securing the publishing process.

There are additional best practices identified by _sonalkr132 in #2698 (comment) that could be exposed as further evidence:

have enabled MFA, are signing your code, don't have any inactive co-owner, are using scoped API keys, have gem notifications enabled, etc

[jchestershopify]

I'd like this to be something users must opt in to (e.g. show_mfa: true): so the feature can't enumerate "weaker" accounts without MFA, only reassurance of accounts with MFA enabled.

I'm not wholly convinced by this. I think making it opt-in will cause very low take-up, so the signal will be unreliable. It also means we can't rely on very soft shame as an incentive to enable MFA on accounts.

Most attacks on accounts will be done in bulk. The accounts at risk stay the same whether or not they are enumerable and for the scale of accounts involved, forcing full enumeration won't be a significant slowdown.

[rubyFeedback]

What is "soft shaming", can you explain this term please?

I would like to hear the explanation before I can respond.

In regards to opt-in versus opt-out: since opt-in is less disruptive
the suggestion by thepwagner is simpler. Those who want it
can enable it; and others who can not or do not want to use it
don't have to change anything either. But I'd love to hear a
full explanation of "soft shaming". Somehow it conjures up
a mental image of people in a school class and the odd one
in the class sitting in the corner, facing the wall.

[thepwagner]

It also means we can't rely on very soft shame as an incentive to enable MFA on accounts.

That's the line I was hoping to avoid: as a maintainer I'd be open to an issue with a tone of "do you have rubygems MFA enabled? would you mind proving it?" versus "why haven't you enabled MFA yet? the fate of my product depends on you!"

[flavorjones]

I think it's reasonable to avoid surprising people by simply making this setting visible, without prior warning. Would y'all be open to declaring an intention to make this setting visible in the future, and encourage gem maintainers to proactively turn on MFA in a healthy, positive way (without public shaming)?

[jchestershopify]

I'd buy something like sending an email well in advance that it would happen, and framing it so that an MFA badge is simply missing if it's not set (so no nag-like "MFA disabled!" badge anywhere). But if the signal is to be meaningful, it has to be fully automated at some point.

[flavorjones]

@kddnewton just submitted a PR to expose this information. I don't feel like we've resolved that bigger strategy conversation about how to get everyone to a point where they're comfortable exposing that information.

My question above was:

Would y'all be open to declaring an intention to make this setting visible in the future, and encourage gem maintainers to proactively turn on MFA in a healthy, positive way (without public shaming)?

I know @jchestershopify agrees with me 🤣 but I'd love to understand how the maintainers feel about it? I'm keen to find a path forward and not lose momentum on this topic.

[kddnewton]

lol my bad didn’t see this issue I was just trying to write a bundler plugin and needed this info.

…

On Wed, Oct 27, 2021 at 3:57 PM Mike Dalessio ***@***.***> wrote: @kddnewton <https://github.com/kddnewton> just submitted a PR to expose this information. I don't feel like we've resolved that bigger strategy conversation about how to get everyone to a point where they're comfortable exposing that information. My question above was: Would y'all be open to declaring an intention to make this setting visible in the future, and encourage gem maintainers to proactively turn on MFA in a healthy, positive way (without public shaming)? I know @jchestershopify <https://github.com/jchestershopify> agrees with me 🤣 but I'd love to understand how the maintainers feel about it? I'm keen to find a path forward and not lose momentum on this topic. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#2813 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABG3P3VZ43Y6CLFA4IU3EZDUJBKTBANCNFSM5FJGFTUQ> .

[sonalkr132]

IMHO, we should come up with positive nudges similar to opt-in for MFA requirement we released recently. The gems which have opt-in will get to show REQUIRES MFA ACCOUNTS: Since <version> on their page. It fits suitably for "you can trust me".
We would need more comments on this issue justifying the use-case for exposing mfa_level information before we can move ahead.

[kddnewton]

My use case is that I would like to only install gems whose authors have MFA enabled. I figure I can write my own bundler plugin that will handle this logic for me, but only if an API exists that will expose that information. So that's why I'd really like for that information to be available.

It's all well and good to expose the information on the rubygems.org webpage - I think that's a great addition! But I can't imagine the most common workflow is for people to go to that page as opposed to the associated repository.

[aellispierce]

Adding another use case here:

As a part of #2755, this work would be helpful in enabling MFA on api keys created on gem signin in the CLI.

We only want to ask a user if they would like to enable mfa on new keys if they have account mfa levels of ui_only or ui_and_gem_sign. Users that have MFA disabled or those that have it enabled for ui_and_api should not be prompted, as it should be auto enabled or disabled for those levels.

Exposing mfa level in the API allows us to make this distinction.

[sonalkr132]

this work would be helpful in enabling MFA on api keys created on gem signin in the CLI.

I don't think we need to make mfa levels public for this use-case. It should be doable with an auth API where you fetch your own mfa level. "I would like to only install gems whose authors have MFA enabled" is the only somewhat valid use-case that has come up.
I for one, don't feel this is an idea we need to act on only one basis of this one use-case. IMHO, it will inevitably fall in the category of "shaming" and not "encouraging". We can consider indirectly using MFA for scoring for the mentioned use-case (see https://github.com/ossf/scorecard).

[aellispierce]

I don't think we need to make mfa levels public for this use-case.

Okay, that's fair! I've opened #2922 to only return the mfa level on authenticated calls for now.