Posted: 5/13/2026 10:13:12 AM EDT
Bambu has been drawing negative attention lately. Open source and AGPL related. Bambu Lab 3D printers: Never again  Bambu Lab: I'm reposting your code & I dare you to sue me. |
|
I honestly don't really care as long as the Bambu ecosystem continues to work as it has in the past. I just want an appliance and am fine being stuck in their ecosystem just like I am with my iPhone. If they break their ecosystem then I'll have to look elsewhere. |
|
Originally Posted By Firestarter123: I honestly don't really care as long as the Bambu ecosystem continues to work as it has in the past. I just want an appliance and am fine being stuck in their ecosystem just like I am with my iPhone. If they break their ecosystem then I'll have to look elsewhere. Agreed......I see the value in open source systems and I'm glad they exist and that people want to put the time/effort into them. |
EP429: Today's lesson - Don't provoke ARFCOM. People will see your butthole.
|
Originally Posted By Firestarter123: I honestly don't really care as long as the Bambu ecosystem continues to work as it has in the past. I just want an appliance and am fine being stuck in their ecosystem just like I am with my iPhone. If they break their ecosystem then I'll have to look elsewhere. Bambu knows this is the case with 99.999% of their users. Half of me thinks they pull this shit just to drum up some free publicity. |
Joined:
Sep 2022
Posts:
2632
EE: 0% (0)
USA
|
Originally Posted By Firestarter123: I honestly don't really care as long as the Bambu ecosystem continues to work as it has in the past. I just want an appliance and am fine being stuck in their ecosystem just like I am with my iPhone. If they break their ecosystem then I'll have to look elsewhere. They're not dumb: they'll break the ecosystem only once they've extinguished all the viable competition. At which point you wont have 'elsewhere' anymore, at least not at a reasonable price/performance point. |
|
Originally Posted By bulldog1967: This pisses me off as Orca slicer is a thousand times better than the Bambu slicer. To be clear, Orca Slicer is not involved with this at all. This is concerning an unaffiliated individual dev who created his own fork of orca slicer. |
 GAMERSNEXUS JOINS FIGHT AGAINST BAMBU LAB F-k You, Bambu Lab: OrcaSlicer-BambuLab Download (with permission) |
"Bureau of Alcohol, Snuff, Firearms and Explosives" Google translator. @Everrest
|
Josef Prusa weighs in https://x.com/i/status/2054602354851254330
|
|
Originally Posted By Blob: Josef Prusa weighs in https://x.com/i/status/2054602354851254330
Thanks for posting. I'll take Josef at his word and assume this is all true. And in that case, very interesting posts. I'll d/l the OSBL fork and see if it works, but I'm curious, why anybody that doesn't trust Bambu, would still want to use OSBL to talk to their cloud vs. airgapping it on a LAN? |
|
Like I mentioned in the other thread I am only casually familiar with this latest ordeal so I did a little more reading up on it. This is what I understand: 1. People want to use Orca Slicer with their Bambu printers 2. Orca Slicer does not provide users with full access to some Bambu features. What these features are I am still unclear about 3. The OS/BL fork connects to Bambu Cloud by pretending to be a legitimate copy of Bambu Studio, thus granting full access to features from bullet #2 4. Bambu's official statement says basically that they do not want an untold number of illegitimate server requests which could cause outages to their cloud network Is this right? Assuming this is true I gotta say I think BBL is well within their rights here, but with all the buzz on reddit (which is really fucking hard to follow) it seems like I'm still missing something. I'm completely onboard with the OS/BL fork emulating BBS to unlock full functionality because yes, you should be able to do whatever you want with your own hardware, but going through Bambu's own cloud server to do so isn't the right way to go about it. At the same time, it's pretty shitty that BBL restricts access to these functions unless you are using their official software that must connect to their servers. Originally Posted By -Obsessed-: I'll d/l the OSBL fork and see if it works, but I'm curious, why anybody that doesn't trust Bambu, would still want to use OSBL to talk to their cloud vs. airgapping it on a LAN? Maybe it's not about security concerns at all and people just want to use Orca for its capabilities while still retaining full printer functionality - which is totally valid. But I don't know what their motivations are. |
|
Originally Posted By Blob: Like I mentioned in the other thread I am only casually familiar with this latest ordeal so I did a little more reading up on it. This is what I understand: 1. People want to use Orca Slicer with their Bambu printers 2. Orca Slicer does not provide users with full access to some Bambu features. What these features are I am still unclear about 3. The OS/BL fork connects to Bambu Cloud by pretending to be a legitimate copy of Bambu Studio, thus granting full access to features from bullet #2 4. Bambu's official statement says basically that they do not want an untold number of illegitimate server requests which could cause outages to their cloud network Is this right? Assuming this is true I gotta say I think BBL is well within their rights here, but with all the buzz on reddit (which is really fucking hard to follow) it seems like I'm still missing something. I'm completely onboard with the OS/BL fork emulating BBS to unlock full functionality because yes, you should be able to do whatever you want with your own hardware, but going through Bambu's own cloud server to do so isn't the right way to go about it. At the same time, it's pretty shitty that BBL restricts access to these functions unless you are using their official software that must connect to their servers. Maybe it's not about security concerns at all and people just want to use Orca for its capabilities while still retaining full printer functionality - which is totally valid. But I don't know what their motivations are. You have the broad strokes nailed down. The primary feature that is locked out on OS (well, before this controversial OSBL fork) is the cloud connection. To be 100% clear, you CAN use OS to send prints directly to your BBL printer, you just have to do it over LAN mode, NOT via their cloud service. The original reason given (which they are sticking to it seems) is that by allowing 3rd party slicers to authenticate connections to their cloud service, there is the potential to use that as a back door (or really, a front door) to attack said cloud network. That sounds very feasible to me, but I'm admittedly not an expert. The issue with this particular fork, is that proprietary, closed source authentication keys were extracted from the closed source part of the BBS code (which technically loads at runtime, and is their reasoning for it not being open source as it's not technically a part of BBS, which is true, but a lame excuse admittedly), but they did it to keep 3rd parties out of their cloud service. Anyway, this developer used these authentication keys to trick the servers at BBL to believe this to be a legitimate copy of BBS, and so it's violating their ToS as you're spoofing an authentic piece of software vs. showing up as OS, which would be denied entry. To be fair to BBS, they offered to make the Bambu Connect app (which is a third party app that is currently standalone to ensure that no malicious connection is formed) an API that could load at runtime for OS just like the network plugin runs at runtime for BBS, but OS told BBL to fuck off and that they'd never implement a 3rd party piece of code into their fork. Which is their choice, but in full fairness, BBL offered to make it a plugin just for them to allow for a seamless experience while having SOME control over the OS connection to the cloud. Which I think was a fair middle ground, but by saying so I'll probably be called a commie. Not saying there isn't something malicious going on under the surface, but I genuinely don't believe it to be the case. I genuinely don't think BBL gives a shit about the benchy you print or the Glock lower you print. If anything, it would undermine the US Govt to let you do whatever the hell you want and not report it. I think that this is just them playing by the rules their government imposed, and maybe this is a strategic area for them, maybe it's not, but I do believe them doing widespread IP theft is not the end goal here...nobody that does serious R&D is using a BBL printer connected to their cloud service. It's going to be airgapped, or more likely than not going to be a true industrial printer like a Modix, Stratasys, etc. But who knows, maybe I'm wrong. |
| Hmm. Yeah it does seem like this is getting blown way out of proportion. As much as I disagree with Bambu's philosophy I don't think this latest drama is going to move the needle on my "fuck bambu" meter at all unless something else that I've missed comes to light. |
|
Can you cite where the closed source authentication keys were extracted? I haven't seen this mentioned anywhere else and there wasn't anything about it in Bambu's statement. There is also this: Attached File https://www.reddit.com/r/OpenBambu/comments/1tfc3xm/dont_forget_bambu_posted_the_workaround/ |
|
Originally Posted By Blob: Can you cite where the closed source authentication keys were extracted? I haven't seen this mentioned anywhere else and there wasn't anything about it in Bambu's statement. There is also this: https://www.ar15.com/media/mediaFiles/160722/Screenshot_2026-05-17_161019_jpg-3763985.JPG https://www.reddit.com/r/OpenBambu/comments/1tfc3xm/dont_forget_bambu_posted_the_workaround/ Fascinating. I can't find that article now but it was an article. I'm wondering if it was due to more info not being readily available or if they originally assumed it was the same authentication keys that were extracted from the firmware that was reverse engineered back when they first implemented the security measure. This isn't even authentication, arguably, the articles I'm seeing now state that it was a simple text string that is arguably meta data though the functionality of such is, in Bambu's mind, the authentication of the software (shitty authentication if so), and is not in the closed source piece at all (which the extracted authentication keys from the firmware on the X1C obviously was closed source) it looks like OSBL took a different approach of authenticated by simply using a meta data text string in the open sourced code. So, in light of that, I don't think BBL has a leg to stand on, and they will need to adjust their so called authentication to really be more than a meta data text string if they hope to enforce it. Pretty big miss on their part if so, which the latest articles seem to suggest. Yikes. |
|
Originally Posted By Blob: Can you cite where the closed source authentication keys were extracted? I haven't seen this mentioned anywhere else and there wasn't anything about it in Bambu's statement. There is also this: https://www.ar15.com/media/mediaFiles/160722/Screenshot_2026-05-17_161019_jpg-3763985.JPG https://www.reddit.com/r/OpenBambu/comments/1tfc3xm/dont_forget_bambu_posted_the_workaround/ So, instead of forging a fake ID, they slapped a name tag on with BambuStudio written on it? |
|
Originally Posted By Moondog: So, instead of forging a fake ID, they slapped a name tag on with BambuStudio written on it? Lol basically. Weak attempt at security. Keep that in mind when you're installing their |