Rules of Engagement for Forking a Dependency
summary
Customers flag a vulnerable dependency via Dependabot and the response follows a concrete four-step escalation: check for an existing issue or PR, raise an issue, submit a PR with the actual fix, and only when those fail fork and publish a variant. Examples include forking a UTF‑7 package and publishing to Pub.dev, running private forks for transitive problems like ssh2/ssh4, and the rule is used repeatedly when maintainers become unresponsive.
AI-written summary · about
chapters (9)
- 0:00Introduction to vulnerability response
- 1:31Four-step rules of engagement
- 2:36Military concept of rules of engagement
- 3:19Step one check existing issues
- 4:23Step two raise an issue
- 5:25Step three submit a PR
- 6:47Step four fork and publish
- 7:52Example of forking a package
- 9:37Recap and conclusion
related talks
29mPlan to fork (So you don't have to fork)
19mFork It for Fun and Profit
06mHow the Fork Do I Contribute to Open Source
32mA Fork to Reckon With: Minimizing Friction When Adopting OSS
32mYou Never Know When You Need a Fork: Lessons Learned Building...
44mThe Social Coding Contract
37mHow to handle abandoned projects, Take Two
23mTowards a Better Adoption Model