51–60 of 122 posts
Earlier quoted context omitted.
Tellingly, this pull request is coming from a Bambu Lab employee. I think the OrcaSlicer maintainers should tell Bambu Lab to pound sand with this change.
> I think the OrcaSlicer maintainers should tell Bambu Lab to pound sand with this change. Hum, the alternative is OrcaSlicer stops working with Bambu printers...
Meanwhile Jeff Geerling already put a video out on his second channel that he won’t recommend a bambu lab printer anymore although he was happy with his printer. And this update didn’t convince him to change his mind. “Developer mode” isn’t a solution. You buy hardware and it should work 100% without cloud connectivity. Otherwise it’s not your hardware.
Earlier quoted context omitted.
> I think the OrcaSlicer maintainers should tell Bambu Lab to pound sand with this change. Hum, the alternative is OrcaSlicer stops working with Bambu printers...
You mean Bambu Lab broke compatibility with OrcaSlicer and every other slicer out there. I don't know if the OrcaSlicer maintainers feel this way. But if they feel that Bambu Lab is stabbing them in the back, they don't have to jump when Bambu Lab tells them to (that's pretty much the raison d'être of open source).
The raison d'être of Orca Slicer is to slice files for 3D printers. They don't manufacture printers. They have no raison d'être if they don't support one of the major players in the 3D printing space.
Seems like the maker community, esp. YouTube influencers, uniformly recommend bambu. Curious-- do folks here have other recommendations? Equivalent quality, speed, maybe even price, but more committed to free software?
Earlier quoted context omitted.
To me this whole thing feels like they're trying to pass audit to sell Bambu printers to corporations that require secure communications. Mutual TLS with client certs is nearly universal, which is what they're trying to do with Bambu Connect. On the other hand, MQTT isn't a very secure protocol, plus the printer also uses FTP which is mostly banned on corporate networks these days.
I wasn't aware of any specific vulnerabilities in the basic MQTT design (assuming it's over TLS). I agree that MTLS for embedded m2m/IOT auth against MQTT is pretty standard (see AWS IOT, Azure etc) but do paper printers used in enterprise which have displays typically require MTLS for printing? Surely any corporation with a security team would VLAN and null route these things anyway - only the enterprise targeted X1…
Most corps these don't want to deal with the hassle of VLANs and black holes for insecure devices.
Earlier quoted context omitted.
I don't really see what having a "developer mode" offers here beyond the existing solution. The current mqtt is already locked down with a unique password and AFAIK the endpoint was read-only anyway. Don't get me wrong I'm glad they're responding to feedback but the feedback shouldn't have been required in the first place. I'm all for better security on products(esp ones that heat up to 300C!) but interoperability wi…
Developer mode is just "how it works today" mode. It's insecure, and uses private APIs, and thus shouldn't be used, but people will anyway, so they're listening to their customers.
For LAN mode yes, but for how the printer works — not exactly. Right now you can print from a 3rd party slicer (Orca Slicer) and at the same time use Bambu Handy mobile app to for example monitor the print. LAN mode disables the cloud connection (always has). Which means that with the revised changes you have to choose either a 3rd party slicer _or_ active cloud connection
Earlier quoted context omitted.
> This addresses nothing. This does in-fact address quite a bit, because they have change their stance with this update. Previously even LAN only mode required to go via their bambu connect system, now you can switch it to developer mode and talk freely via MQTT to the printer.
Why should I switch to "developer mode" to talk to a computer I own on my own network?
Or you can turn off security and use "developer mode", aka. "how things work today" mode, if you want to do things the old / insecure way.
Uh-huh. So exactly what threat or threats is the "security upgrade" meant to address, what alternatives were considered, and where the heck is the "security" in sticking a barely obfuscated private key in a publicly distributed binary?
The security threat is real, they got ddos attempt to their mqtt service last year from 3rd party apps. The fix is not good though, distributing private key.