[HN Gopher] Making popular Ruby packages more secure ___________________________________________________________________ Making popular Ruby packages more secure Author : tomstuart Score : 82 points Date : 2022-06-13 19:12 UTC (3 hours ago) (HTM) web link (blog.rubygems.org) (TXT) w3m dump (blog.rubygems.org) | mhoad wrote: | Throwing the black hat on for a moment surely I would just move | towards the subdependencies of these popular gems (which | realistically is where you would be targeting anyways I imagine) | and can fairly reliably expect that my malicious changes get | picked up upstream in due course. | | Am I missing something here? | joevandyk wrote: | Those dependencies will be downloaded more often than the | "popular" gems, so they will be affected by the same policies. | mhoad wrote: | Cool that's what I wanted to clarify. Thank you. | colechristensen wrote: | I see this kind of comment often, somebody implements a solid | security improvement measure and a popular response is "what | about x!?" | | No, enabling MFA for the most popular packages won't end all | security, but also your strategy of targeting subdependencies | isn't very good, every dependency of a popular project will be | more popular than its dependent parent. | Gigachad wrote: | I'd imagine this would end up being rolled out to almost all | users eventually. Getting the top 100 done is just the warm up. | ufuk wrote: | This is a great first step to making dependencies more secure in | the Ruby ecosystem. Congrats to the whole team for getting this | done! | tessierashpool wrote: | yes indeed. hats off to the people working hard to make things | better for everyone in Ruby. | Gigachad wrote: | TFA truly was a blessing for security. Finally _something_ that | can just be blindly mandated and actually works wonders. User | training was not getting anywhere. | codebeaker wrote: | As part of a team of maintainers of a popular (declining) gem, | shame they don't make a mention of the extremely valid "gem is | owned by a team, and anyone may push" model. I regret that the | MFA token for many gems such as this may end-up in 1Password or | similar, shared, along side the other credentials, rather than on | a separate device or similar. | eropple wrote: | I'm having trouble parsing your post. You can add multiple | owners to a gem. You can also disable 2FA for API access on a | per-account basis (though it isn't recommended) for a CI runner | --which, tbh, is how a popular gem _should_ be being published. | What 's the objection here? | msbarnett wrote: | Gems can have multiple accounts able to push, and MFA tokens | are per-account, not per-gem. So what's the issue exactly? | tessierashpool wrote: | seems like the post you're replying to had already answered | your question, in its second sentence: | | > I regret that the MFA token for many gems such as this may | end-up in 1Password or similar, shared, along side the other | credentials, rather than on a separate device or similar. | msbarnett wrote: | Still not following. | | "> I regret that the MFA token for many gems such as this | may end-up in 1Password or similar, _shared, along side the | other credentials,_ rather than on a separate device or | similar. " | | Emphasis mine. How does "the extremely valid "gem is owned | by a team, and anyone may push" model" impact this in any | way? Why would the MFA tokens need to be _shared_ via | 1Password if they are specific to an individual account? | | Unless you're sharing the username/password for a master | account between everyone with push access to the gem | (which, I checked, Capistrano thankfully doesn't appear to | be doing), there's no reason whatsover to share the MFA | token, so it could happily exist on a separate device. And | if you _are_ sharing one username /password between | everybody - don't do that. You don't need to do that to | accomplish "the extremely valid "gem is owned by a team, | and anyone may push" model". That's just a really stupid | way to do anything. | | GP seems to be thinking that everyone with push rights | needs to share the same token, but that's simply incorrect. | jacques_chester wrote: | In fact, you can now scope API tokens per-gem as well: | https://github.com/rubygems/rubygems.org/pull/2944 ___________________________________________________________________ (page generated 2022-06-13 23:00 UTC)