[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)