Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Bambu Lab - Setting the Record Straight About Our Security Update

blog.bambulab.com

Post reply on HN
Print view View original

61–70 of 122 posts

Re: Bambu Lab - Setting the Record Straight About Our Security Update

#61

Post by ipv6ipv4 »

iLoveOncall wrote: post #54
ipv6ipv4 wrote: post #27

Earlier quoted context omitted.

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).

> 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.

OrcaSlicer is sponsored by Qidi and BigTree Tech. If anything, Bambu Lab is taking them for a ride, like it is taking the rest of the open source community for a ride.

It's clear you like your Bambu Lab printer/s. But I think you are letting it cloud your judgement. Bambu Lab is being predatory here.

Re: Bambu Lab - Setting the Record Straight About Our Security Update

#62

Post by parasubvert »

hn8726 wrote: post #58
parasubvert wrote: post #43

Earlier quoted context omitted.

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.

> Developer mode is just "how it works today" mode. 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 con…

Hmm, seems pretty clear that OrcaSlicer will eventually adapt to use Bambu Connect regardless, which will preserve active cloud connections.

Re: Bambu Lab - Setting the Record Straight About Our Security Update

#63

Post by Maskawanian »

parasubvert wrote: post #41

People seem to be missing that FTP and MQTT are generally insecure protocols. I think FTP is probably the bigger issue than MQTT. This kind of stuff is common in home IOT networks but would never pass security audit on a corporate network. Bambu is growing up, serving more corporations beyond the hobby community, and probably has been asked to beef their security up to make it easier to deploy their printers securely…

MQTT is not inherently insecure. Much like HTTP, there is a encrypted version that runs on port 8883.

Re: Bambu Lab - Setting the Record Straight About Our Security Update

#64

Post by sho_hn »

parasubvert wrote: post #59
sho_hn wrote: post #31

Earlier quoted context omitted.

Why should I switch to "developer mode" to talk to a computer I own on my own network?

You don't need to. You can use their Bambu Connect client in LAN mode. 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.

Insecure for who? What's the threat vector?

Re: Bambu Lab - Setting the Record Straight About Our Security Update

#65

Post by parasubvert »

ipv6ipv4 wrote: post #61
iLoveOncall wrote: post #54

Earlier quoted context omitted.

> 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.

OrcaSlicer is sponsored by Qidi and BigTree Tech. If anything, Bambu Lab is taking them for a ride, like it is taking the rest of the open source community for a ride. It's clear you like your Bambu Lab printer/s. But I think you are letting it cloud your judgement. Bambu Lab is being predatory here.

Bambu Lab isn't being predatory. They're making a sensible change to their security.

But, because people don't understand security technology tradeoffs, everything becomes a conspiracy.

Re: Bambu Lab - Setting the Record Straight About Our Security Update

#66

Post by KMnO4 »

aweiland wrote: post #55
igor47 wrote: post #52

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?

Prusa

Prusa does not have an equivalent printer to the P1S/X1C. Even their Mk4s is twice the price of an A1 and is missing some basic features that come standard on all Bambu Lab printers (such as a camera).

Re: Bambu Lab - Setting the Record Straight About Our Security Update

#67

Post by VogonPoetry »

wildzzz wrote: post #11
scblock wrote: post #3

The list of fake concerns they list are not the real and very valid concerns I have seen. This addresses nothing.

These companies always pick the most ridiculous tinfoil hat bullshit list of complaints to debunk when trying to explain why they want to close off their API. The real reason almost always comes down to money. The mention of Panda Touch is very telling. While I'm sure Bambu doesn't want to maintain documentation for a non-public (is that the right term)? API, they definitely don't want other companies making money of…

What if this is not about closing off an API. Maintaining a stable API is difficult - especially if mistakes were made in earlier designs (no versioning, bad abstraction, wrong protocol...) and there is a plan to fix things in the future.

Only the maintainer of an API knows what the future plans are. Not making future plans public is the way to avoid Osbourne incidents and to actually deliver real things, not just vacuous promises.

From my dabbling with MQTT, Tasmota and home built sensors; MQTT has no versioning and limited hierarchy in the pub / sub model. I'm not surprised Bambu didn't want a 3rd Party product to "integrate" with it. (Disclaimer, I don't know what it is used for, I don't have the products)

In my experience, if you need to fix something that has an undesigned API or needs interfaces or communications methods to change, what you do is build a "New Interface" with what you want and temporarily bridge it to the old one. The desired plan is, once everyone moves to the new interface, the old things can be sunset.

Sadly, this is the utopian view. From what I've seen, 3rd Parties often give the middle finger and just keep using the old stuff. The 3rd parties or customers then complain bitterly when the "New Interface" only comes out - the "blame", rightly or wrongly, is usually directed at the software update. Shouldn't 3rd Parties also be held to account and have a duty to maintain their integrations?

Building, supporting and evolving products is challenging - I've rarely see people put the right structure in place for v2.0, v3.0 when frantically working to get v1.0 out. Mistakes will be made and they are very, very expensive to fix (reputation, engineering time, QA) in the future.

From the statement made, I await a response from Panda Touch - will they commit to fixing their product and inform their customers?

Re: Bambu Lab - Setting the Record Straight About Our Security Update

#68

Post by parasubvert »

Maskawanian wrote: post #63
parasubvert wrote: post #41

People seem to be missing that FTP and MQTT are generally insecure protocols. I think FTP is probably the bigger issue than MQTT. This kind of stuff is common in home IOT networks but would never pass security audit on a corporate network. Bambu is growing up, serving more corporations beyond the hobby community, and probably has been asked to beef their security up to make it easier to deploy their printers securely…

MQTT is not inherently insecure. Much like HTTP, there is a encrypted version that runs on port 8883.

That... doesn't make things particularly secure. First of all MQTT doesn't require authentication. Secondly FTP is involved which is generally deprecated on most sensible servers and networks. Finally, sending passwords in the clear over an encrypted wire to an end device has been an obsolete technique for over 20 years. People still do it, but they shouldn't. It's the reason we have Kerberos, OAuth2/OIDC, and x509 client authentication with Mutual TLS.

Re: Bambu Lab - Setting the Record Straight About Our Security Update

#69

Post by sho_hn »

parasubvert wrote: post #47
sho_hn wrote: post #40

Earlier quoted context omitted.

> Hum, the alternative is OrcaSlicer stops working with Bambu printers... Which is fine, no? Plenty of other good printers available.

Um no? First, Bambu is the best, by far. Secondly, Orca Slicer is a fork of Bambu Studio and the vast majority of its users are Bambu customers that want extra features.

> Bambu is the best, by far.

Nah, this is influencer-generated bro science sentiment. They do nothing special, and hardly never come out on top in any serious independent print quality tests.

Their primary competitive advantage right now the AMS bundle being very competitively priced.

Re: Bambu Lab - Setting the Record Straight About Our Security Update

#70

Post by Maskawanian »

parasubvert wrote: post #68
Maskawanian wrote: post #63

Earlier quoted context omitted.

MQTT is not inherently insecure. Much like HTTP, there is a encrypted version that runs on port 8883.

That... doesn't make things particularly secure. First of all MQTT doesn't require authentication. Secondly FTP is involved which is generally deprecated on most sensible servers and networks. Finally, sending passwords in the clear over an encrypted wire to an end device has been an obsolete technique for over 20 years. People still do it, but they shouldn't. It's the reason we have Kerberos, OAuth2/OIDC, and x509 c…

Nah, you made an absolute statement that MQTT was insecure, that was demonstrated to be incorrect. If HTTP can be made secure by relying on a secure transport, then MQTT can as well.

Additionally, MQTT does allow for authentication. I've personally set up brokers many times that will not allow anonymous connections.

Misconfiguration of services, does not constitute an error in the protocol itself.

Post reply on HN