The uncomfortable truth about open-source software
RECODE.AM #44
A few days ago, the community around OrcaSlicer - one of the most popular open-source slicers - celebrated a new release. The changelog was long, the fixes solid.
But in that list, somewhere between interface improvements and new material profiles, there was an entry that should inspire more concern than excitement.
A security patch. A serious one. Related to how the software handles project files.
OrcaSlicer contained a vulnerability enabling a so-called “zip-slip” attack via 3MF files.
3MF project files are essentially compressed archives. The slicer extracts them in the background, invisibly to the user. And that’s where the problem lay: a carefully crafted file could write data outside the intended system directory, into arbitrary locations on the disk.
From there, it’s only a small step to executing malicious code.
In other words: simply opening a file from an untrusted source could infect a computer. Such a file could sit quietly in a model repository, appearing perfectly normal and ready to print.
The vulnerability existed until one user - “Zekun Shen” - reported it.
The latest update fixes it. That’s good.
But wait - is that really enough to close the case?
Before I go further, let me be clear: I’m not writing this to attack the open-source community. Quite the opposite. The people developing this software do it out of passion, for free or close to it, often after hours.
The results are often impressive. Their commitment is real and deserves respect.
But precisely because of that, I need to say something difficult…
A community is not a company
It doesn’t sign service-level agreements. It doesn’t bear legal responsibility. It doesn’t have a security department tracking CVEs, testing releases before deployment, and responding to incidents within 72 hours. It reacts when someone finds something and chooses to report it.
In open source, the gap between discovery and disclosure can be a week, a month - or a year. Or never.
Someone will always say: “But Linux is open source and it’s secure.” Or: “LibreOffice is open source, and public institutions use it.”
Yes. But those projects have decades of development behind them, hundreds of active contributors, dedicated organizations and foundations, and commercial sponsors with budgets for security audits.
The open-source ecosystem for FFF 3D printing slicers is not Linux. It’s an enthusiastic, talented - but incomparably smaller - community operating without that infrastructure. Treating them as equivalent isn’t belief in open source - it’s a misunderstanding of scale.
Let’s return to printer manufacturers
There are companies on the market that have built excellent hardware - and stopped right there. Slicer? Take something open source, fork it, add a logo.
Ecosystem? The community will handle it. Software security? Well, we didn’t write it.
That’s a strategy that looks reasonable in the short term. In the long term, it’s a mistake.
A 3D printer today is not just a machine. It’s an entry point into a process that begins on a screen and ends on a build plate. Every step along that path - from designing the model, to slicing it into layers, to managing the print - happens in software.
If a manufacturer does not control that software, it does not control the user experience. It does not control security. It does not control what it is actually selling.
Hardware is the easiest part of this puzzle to copy. Motors, rails, extruders - all of it can be replicated. But software that is cohesive, secure, tested, and maintained by a responsible team - that cannot be copied in a quarter.
A slicer vulnerability is not just a technical issue. It’s a question of responsibility.
When a user downloads a model from a popular repository and opens it in a slicer, they assume someone is watching over it. That someone, somewhere, has tested it, checked it, secured it.
A printer manufacturer that recommends specific software - even if they didn’t write it - implicitly takes responsibility for it in the eyes of the user. The user doesn’t make that distinction.
They only know they bought a printer from that company and found a link to that software on its website.
Responsibility does not disappear by saying, “it’s open source, we just recommend it.”
That’s why companies that take their place in the market seriously should take software seriously. Not as a cost to avoid by using someone else’s work - but as a foundation without which hardware is only half a product.
The community gives a lot. But it does not provide guarantees. And it should not be forced to carry a burden that belongs on the shoulders of the manufacturer.
A printer without software is a machine without a brain. A printer with software no one is responsible for is a machine with a brain borrowed on trust.
I have not being using ORCA slicer for a while now, my main printers use BambuStudio and Creality Print, I recently I started saying, for the numbers of supports, that have first the latest new feature is not all, it is worth wait for it to come to the manufacture slicer, even if it takes time, so it come fixed. Your words just make me feel right about it. I was totally not aware of this problem, it is good to learn about it after it is fixed, but even so, it just make me feel better about this way of waiting for the features. It is really worth.
Who are these mythical companies with 72 hour response time to CVEs? Hell, where are the companies who test their software?
Microsoft, Google, and Amazon certainly aren't. SAP, atlassian, crowd strike aren't either.
Business to business contracts might place responsibility on the manufacturer, but that doesn't mean they're going to bother fixing issues. They'll just ignore them, and maybe give you a discount off your nest renewal.
At least if it's open source you can monkey patch while you wait for their "security" team to decide if they even want to acknowledge it.