121212 2 OpenSwissKnife

Here's how open-source is supposed to work: A goup releases a product, with the source code freely available. Someone finds a problem. They solve the problem, issue a pull request, and the creators merge that into the product, making it better for everyone.

Here's another way open-source is supposed to work: A group releases a product, with the source code freely available. Someone finds a problem, but they can't fix it themselves, so they issue a bug report. Someone else fixes the problem, issues a pull request, and the creators merge that into the product, making it better for everyone.

Here's one way open-source works: Someone creates a product. It gets popular—and I mean really, really popular, practically overnight. The creator didn't ask for this. They have no idea what to do with success. They try their best to keep up, but they can't keep on top of everything all the time. They haven't even set up a build pipeline yet. They're flying by the seat of their pants. One day, unwisely choosing to program with a fever, they commit broken code and push it up to GitHub, triggering an automatic release. Fifteen thousand downstram dependencies find their build broken and show up to scold the creator for not running tests before releasing.

Here's another way open-source works: A group creates a product. It gets popular. Some time later, there are 600 open issues and over 50 pending pull requests. The creator hasn't commented in a year, but people keep vainly trying to improve the product.

Here's another way open-source works: A group creates a product. They decide to avoid the above PR disaster by using some off-site bug tracker. Someone files a bug. Then another bug. Then 5 or 10 more. The creator goes on a rampage, insisting that everyone is using it wrong, and deletes all the bug reports, banning the users who submitted them. The product continues to gain success, and more and more people file bugs, only to find the bug reports summarily closed. Sometimes people get lucky and their reports will be closed, then re-opened when another dev decides to fix the problem.

Here's another way open-source works: Group A creates a product. Group B creates a product, and uses the first product as their support forum. That forum gets hacked. Group B files a bug to Group A, rightly worried about the security of the software they use. After all, if the forum has a remote code exploit, maybe they should move to something newer, maybe written in Ruby instead of PHP. One of the developers from Group A, today's submitter, offers to investigate.

Many forums allow admins to edit the themes for the site directly; for example, NodeBB provides admins a textbox in which they can paste CSS to tweak the theme to their liking. This forum figures that since the admins are already on the wrong side of the airtight hatchway, they can inject bits of PHP code directly into the forum header. Code like, say, saving a poison payload to a disk that creates a endpoint that accepts arbitrary file uploads so they can root the box.

But how did the hacker get access to that admin panel? Surely that's a security flaw, right? Turns out they'd found a weak link in the security chain and applied just enough force to break their way in. If you work in security, I'm sure you won't be surprised to hear the flaw: one of the admins had a weak password, one right out of a classic dictionary list.

Here's another way open-source works: 15% of the NPM ecosystem was controlled by people with weak passwords. Someone hacks them all, tells NPM how they did it, and gets a mass forced-reset on everyone's passwords. Everyone is more secure.

[Advertisement] BuildMaster allows you to create a self-service release management platform that allows different teams to manage their applications. Explore how!