4 ms·

I think that rubygems should consider automatically enforcing multifactor authentication for popular gems. So any gem with more than 50,000 downloads should fo

by sersi 7y ago

I think that rubygems should consider automatically enforcing multifactor authentication for popular gems. So any gem with more than 50,000 downloads should force to gem maintainer to have MFA set up before they can publish a new version or do anything with that gem. Because, having MFA is not about protecting gem maintainers, it's about protecting users. So, gem maintainers should not be allowed to be careless with security by not using MFA. It's not their choice to make.

raesene9 7y ago
It's not just rubygems that has this issue, it's all the other repos too, most of which (AFAIK) don't enforce 2FA Also worth noting that whilst MFA helps, it's not a panacea as MFA isn't generally compatible with automated CI/CD processes, so API keys will still be required, and can be leaked/lost/stolen.
- cooljacob204 7y ago
  Why would a CI/CD need to permissions modify and commit code to a repo?
  - raesene9 7y ago
    Say your CI pipeline runs automated tests, builds the gem and pushes to Rubygems, it needs permissions to push to Rubygems. So if an attacker compromises the API key used by that pipeline, they get the rights to push to Rubygems.
    - enneff 7y ago
      Actually publishing new versions seems like something that happens infrequently enough that it would be fine to require a manual auth to complete it. Given the potential risks it seems prudent.
      - raesene9 7y ago
        I'd expect that very much depends on the software in question. As one example that I'm aware of, gvisor from Google delivers nightly builds. So they're building and pushing every single day. It'd depend on the individual software library and of course as a consumer of many libraries you generally will have limited or no visibility of the practices of all your dependencies.
        rubber_duck 7y ago
        I don't think nightly builds are the same thing as releases - you can have CI publish a build but to create a versioned public release it should require manual auth.
        raesene9 7y ago
        That's a view of course (although in the case of gVisor they don't actually do versioned build just nightlies) but here's a question. As a consumer of software libraries, have you ever looked into the security practices of the library author before choosing whether to use it or not?
        ryanbrunner 7y ago
        This is becoming increasingly impractical for certain ecosystems as packages depend on packages, which depend on packages, etc. It's less of a problem with the bundler ecosystem, where larger packages with relatively few dependencies is more standard, but in the JS world installing a package means that you're likely installing tens or hundreds of sub-dependencies.
        rubber_duck 7y ago
        I did review two small libs I was pulling that had very few users (and froze the version) But that's just the thing - I will never be in a position to do that for more than a few libs - that's why the best I can do is rely on source enforcing good practices and community audits.
        7y ago
    - C4stor 7y ago
      I doesn't seem hard to imagine a CI pipeline that sends an email/sms for validation and waits an affirmative answer before continuing. I have no idea how to receive texts on a server, but sending and receiving emails is super easy.
- sersi 7y ago
  Yes, I agree, it's not only rubygems, npm had the same problem not so long ago and it is a general issue in all repos. One thing that would be inconvenient but would protect against that would be to have the api work as usual, but need to use MFA and login to the website to approve a new release (and have information there listing the ip and time of upload). That would only make sense for heavily used gems like this one but it seems that it would stop most issues?
  - raesene9 7y ago
    It would help for sure, I'd guess the problem would be , will the maintainers of all these libraries be happy with the overhead that this would introduce. A less invasive control might be to notify all owners when a new version is pushed, so they would be aware of a risk, if they weren't expecting a new release. Not perfect, but something.
- andrewaylett 7y ago
  How about a split, so releases can be uploaded by API key, but only published by someone using MFA?
bpicolo 7y ago
Or just any gem, period, regardless of download count? Seems like a fair minimum baseline for publishing to a public repository. MFA in modern times is low-effort.
- krferriter 7y ago
  Yeah should be for all gems, and same goes for npm and pip registries. If you're publishing code to an official public registry for pulling and execution by other users in the ecosystem, multifactor authentication should be required. Agreed that the effort required to add this nowadays is fairly small, such that it should be more widespread.
vesinisa 7y ago
It's only a matter of time before this will happen. Once any one of the big players (rubygems, npm, Maven central, PyPi) enforces 2FA, all other repos will soon have to follow suit or risk giving appearance of haphazard attitude towards user security. 2FA is generally trivial for maintainers to take into use. There is simply no excuse to not require it at this point for all new uploads. The status quo of hoping maintainers never re-use their passwords / use weak passwords / have their machines hacked is clearly not working since security incidents like this keep happening every other week with Rubygems/npm/etc.
- acegopher 7y ago
  PyPi has 2FA for user logins to the website, which: "safeguards against malicious changes to project ownership, deletion of old releases, and account takeovers. Package uploads will continue to work without users providing 2FA codes." They are also working to enforce 2FA on uploads: "But that's just for now. We are working on implementing per-user API keys as an alternative form of multifactor authentication in the setuptools/twine/PyPI auth flows. These will be application-specific tokens scoped to individual users/projects, so that users will be able to use token-based logins to better secure uploads. And we'll move on to working on an advanced audit trail of sensitive user actions, plus improvements to accessibility and localization for PyPI. More details are in our progress reports." From: http://pyfound.blogspot.com/2019/06/pypi-now-supports-two-factor-login-via.html http://pyfound.blogspot.com/2019/06/pypi-now-supports-two-fa...
holtalanm 7y ago
i turned on 2fa for my npm account, and my published libraries aren't even at 1K downloads _total_ yet. these guys with libraries that have a massive user base really have no excuse besides laziness for not having 2fa on their account.

by sersi 7y ago

raesene9 7y ago

It's not just rubygems that has this issue, it's all the other repos too, most of which (AFAIK) don't enforce 2FA Also worth noting that whilst MFA helps, it's not a panacea as MFA isn't generally compatible with automated CI/CD processes, so API keys will still be required, and can be leaked/lost/stolen.

cooljacob204 7y ago
Why would a CI/CD need to permissions modify and commit code to a repo?
- raesene9 7y ago
  Say your CI pipeline runs automated tests, builds the gem and pushes to Rubygems, it needs permissions to push to Rubygems. So if an attacker compromises the API key used by that pipeline, they get the rights to push to Rubygems.
  - enneff 7y ago
    Actually publishing new versions seems like something that happens infrequently enough that it would be fine to require a manual auth to complete it. Given the potential risks it seems prudent.
    - raesene9 7y ago
      I'd expect that very much depends on the software in question. As one example that I'm aware of, gvisor from Google delivers nightly builds. So they're building and pushing every single day. It'd depend on the individual software library and of course as a consumer of many libraries you generally will have limited or no visibility of the practices of all your dependencies.
      - rubber_duck 7y ago
        I don't think nightly builds are the same thing as releases - you can have CI publish a build but to create a versioned public release it should require manual auth.
        raesene9 7y ago
        That's a view of course (although in the case of gVisor they don't actually do versioned build just nightlies) but here's a question. As a consumer of software libraries, have you ever looked into the security practices of the library author before choosing whether to use it or not?
        ryanbrunner 7y ago
        This is becoming increasingly impractical for certain ecosystems as packages depend on packages, which depend on packages, etc. It's less of a problem with the bundler ecosystem, where larger packages with relatively few dependencies is more standard, but in the JS world installing a package means that you're likely installing tens or hundreds of sub-dependencies.
        rubber_duck 7y ago
        I did review two small libs I was pulling that had very few users (and froze the version) But that's just the thing - I will never be in a position to do that for more than a few libs - that's why the best I can do is rely on source enforcing good practices and community audits.
      - 7y ago
  - C4stor 7y ago
    I doesn't seem hard to imagine a CI pipeline that sends an email/sms for validation and waits an affirmative answer before continuing. I have no idea how to receive texts on a server, but sending and receiving emails is super easy.
sersi 7y ago
Yes, I agree, it's not only rubygems, npm had the same problem not so long ago and it is a general issue in all repos. One thing that would be inconvenient but would protect against that would be to have the api work as usual, but need to use MFA and login to the website to approve a new release (and have information there listing the ip and time of upload). That would only make sense for heavily used gems like this one but it seems that it would stop most issues?
- raesene9 7y ago
  It would help for sure, I'd guess the problem would be , will the maintainers of all these libraries be happy with the overhead that this would introduce. A less invasive control might be to notify all owners when a new version is pushed, so they would be aware of a risk, if they weren't expecting a new release. Not perfect, but something.
andrewaylett 7y ago
How about a split, so releases can be uploaded by API key, but only published by someone using MFA?

bpicolo 7y ago

Or just any gem, period, regardless of download count? Seems like a fair minimum baseline for publishing to a public repository. MFA in modern times is low-effort.

krferriter 7y ago
Yeah should be for all gems, and same goes for npm and pip registries. If you're publishing code to an official public registry for pulling and execution by other users in the ecosystem, multifactor authentication should be required. Agreed that the effort required to add this nowadays is fairly small, such that it should be more widespread.

vesinisa 7y ago

It's only a matter of time before this will happen. Once any one of the big players (rubygems, npm, Maven central, PyPi) enforces 2FA, all other repos will soon have to follow suit or risk giving appearance of haphazard attitude towards user security. 2FA is generally trivial for maintainers to take into use. There is simply no excuse to not require it at this point for all new uploads. The status quo of hoping maintainers never re-use their passwords / use weak passwords / have their machines hacked is clearly not working since security incidents like this keep happening every other week with Rubygems/npm/etc.

acegopher 7y ago
PyPi has 2FA for user logins to the website, which: "safeguards against malicious changes to project ownership, deletion of old releases, and account takeovers. Package uploads will continue to work without users providing 2FA codes." They are also working to enforce 2FA on uploads: "But that's just for now. We are working on implementing per-user API keys as an alternative form of multifactor authentication in the setuptools/twine/PyPI auth flows. These will be application-specific tokens scoped to individual users/projects, so that users will be able to use token-based logins to better secure uploads. And we'll move on to working on an advanced audit trail of sensitive user actions, plus improvements to accessibility and localization for PyPI. More details are in our progress reports." From: http://pyfound.blogspot.com/2019/06/pypi-now-supports-two-factor-login-via.html http://pyfound.blogspot.com/2019/06/pypi-now-supports-two-fa...

holtalanm 7y ago

i turned on 2fa for my npm account, and my published libraries aren't even at 1K downloads _total_ yet. these guys with libraries that have a massive user base really have no excuse besides laziness for not having 2fa on their account.