discussions
rfcs
discussions | rfcs | |
---|---|---|
1 | 7 | |
149 | 45 | |
0.0% | - | |
10.0 | 4.6 | |
over 9 years ago | 5 months ago | |
- | - |
Stars - the number of stars that a project has on GitHub. Growth - month over month growth in stars.
Activity is a relative number indicating how actively a project is being developed. Recent commits have higher weight than older ones.
For example, an activity of 9.0 indicates that a project is amongst the top 10% of the most actively developed projects that we are tracking.
discussions
-
NPM Vulnerability Discussion on Twitter
The question in that thread, and this later thread,[1] is how to know which keys are valid to sign a package.
For example: I go to release a new version and I've lost my private key, so I roll a new one -- this will happen often across npm's 1.3 million packages. Do I then ... log in with my email and update the private key on my account and go about my business? What process does npm use to make sure my new key is valid? Can a person with control over my email address fake that process? How are key rotations communicated to people updating packages -- as an almost-always-false-positive red flag, or not at all, or some useful amount in between? If you don't get this part of the design right -- and no one suggests how to in those threads -- then you're just doing hashes with worse UX. And the more you look at it, the more you might start to think (as the npm devs seem to) that npm account security is the linchpin of the whole thing rather than signing.
It's not just npm; that thread includes a PyPI core dev chipping in with the same view: "Lots of language repositories have implemented (a) [signing] and punted on (b) and (c) [some way to know which keys to trust] and essentially gained nothing. It's my belief that if npm does (a) without a solution for (b) and (c) they'll have gained nothing as well." It also has a link from a Homebrew issue thread deciding not to do signatures for the same reason -- they'd convey a false expectation without a solution for key verification.[2]
[1] https://github.com/node-forward/discussions/issues/29
rfcs
-
Ruby Shield: Shopify donates $1M to stewards of rubygems, bundler
I can give a limited answer based on my own day-to-day work. I work in Ruby Dependency Security, which is the team who are most involved in helping out with rubygems.org and RubyGems work. Our biggest effort lately has been about rolling out MFA requirements for owners of top-most-downloaded gems. What I'd like to do afterwards is focus on gem signing using sigstore, which would make it a "one click" experience for authors. We did some work on it earlier this year[0] but chose to focus on MFA as our first big push. We also aim to devote a substantial fraction of our time to chopping wood and carrying water: looking at honeybadger exception reports, etc.
In terms of the long run there's a whole bunch that can be done to continuously harden every aspect of the Ruby supply chain. One thing we've been involved in founding is the OpenSSF Securing Software Repos working group[1], which has meant that RubyGems maintainers are now talking directly with folks from PyPI, npm, Maven Central, Cargo and others. We all face shared threats (eg, dependency confusion, resurrection attacks etc), so getting together to work collectively and share ideas has been super awesome.
[0] https://github.com/rubygems/rfcs/pull/37
[1] https://github.com/ossf/wg-securing-software-repos
-
Making popular Ruby packages more secure
That’s correct. If you’re a maintainer of a very popular gem, as of 15th August you’ll no longer be able to e.g. `gem push` if you haven’t enabled MFA on your RubyGems account. You will of course still be able to log in and enable it.
More details in the RFC: https://github.com/rubygems/rfcs/blob/master/text/0007-mfa-r...
-
NPM Vulnerability Discussion on Twitter
> < 10% had useful 2FA enabled.
I expect this to change. NPM will roll out mandatory MFA for the most-downloaded packages[0] (RubyGems as well[1]). I expect this will rise to a 100% requirement at some point because Github's decision to require MFA by the end of 2023 will massively raise the waterline of folks who have the capability to MFA and experience with MFA.
[0] https://github.blog/2021-11-15-githubs-commitment-to-npm-eco...
[1] https://github.com/rubygems/rfcs/issues/35
-
Sigstore
The RFC trying to introduce sigstore for RubyGems is an interesting look at this in practice: https://github.com/rubygems/rfcs/pull/37
- RFC for Sigstore Rubygems Signing
- RFC: Proposal for new signing mechanism
- Require MFA for most-used gems [RubyGems RFC]
What are some alternatives?
sigstore-website - Codebase for sigstore.dev
harden-runner - Network egress filtering and runtime security for GitHub-hosted and self-hosted runners
npm
enquirer - Stylish, intuitive and user-friendly prompts, for Node.js. Used by eslint, webpack, yarn, pm2, pnpm, RedwoodJS, FactorJS, salesforce, Cypress, Google Lighthouse, Generate, tencent cloudbase, lint-staged, gluegun, hygen, hardhat, AWS Amplify, GitHub Actions Toolkit, @airbnb/nimbus, and many others! Please follow Enquirer's author: https://github.com/jonschlinkert
rubygems - Library packaging and distribution for Ruby.
package-analysis - Open Source Package Analysis
wg-securing-software-repos - OpenSSF Working Group on Securing Software Repositories
warehouse - The Python Package Index
Babel (Formerly 6to5) - 🐠 Babel is a compiler for writing next generation JavaScript.
RubyGems - The Ruby community's gem hosting service.
HomeBrew - 🍺 The missing package manager for macOS (or Linux)