It will be interesting to see how many projects will opt in for this--at least, I assume it's opt in. It would be even more interesting to see how fast projects opt out if it was instead opt out.
GitHub can now automagically offer security patches for projects' third-party dependencies. The Microsoft-owned source-code management site announced on Wednesday the new beta-grade feature: when enabled, developers will receive automatically generated pull requests that, when accepted, will apply security fixes to a project's …
This is another Utopian/Orwellian pipe dream. Take responsibility for your own codebase--all of it. Contribute back. Don't yell at people who are doing stuff for you for free out of the goodness of their heart or the love of their craft.
There was a point release of a common ruby package that broke another package. (The fault was in the second package.) This second package was one of the most popular, but poorly maintained. Messed up builds for several months for a huge swath of the community.
Figuring out if an upgrade will break the build is trivially a Turning complete problem. Pressing volunteers to incorporate "security fixes" is not a healthy long-term solution.
I half agree. Well, actually I mostly agree. What I say is let there be tools and automation, and plenty of them--yet let the owner of the code still step up and take responsibility for the end result. And, tip of the hat to those who build regression testing into their product's version control, so that every new version will automatically have the regression testing that fits the particular version being released. Call it a multi-factored approach; call it defense in depth, but don't call it somebody else's problem when you own the code.
This is a useful feature. You don’t have to use it, but frankly as someone disseminating software to people you have a duty of care to ensure the third party libs you deploy are patched.
“Messed up builds for several months for a huge swath of the community.”
If you’re randomly updating packages without testing first you get what you deserve. That’s why this gives you a pull request, rather than stomping all over your repo. You can (and should!) test, then merge.
The problem is testing is less fun than coding, so when everything is voluntary testing can suffer, and you get the problem you described.
the whole point of using a library is so you concern yourself only with its interface. if some library I use has a bugfix, why should it impact my project that depends on it? Sure, it's wise to have your binaries/libs up to date, but it's not my lib, and I don't care to concern myself with its code at all, just the interface.
Biting the hand that feeds IT © 1998–2020