support bambulab's new security functions #8103
Conversation
verified on 1/19 night
Change-Id: Ifde58610a1db29ba9d87078e605dc556ec0ce148 Signed-off-by: Stone Li <stone.li@bambulab.com>
|
How does this populate AMS filament settings into Orca for code generation before sending the slice file? @lanewei120 |
From what I understand, according to the diagram they posted, the original plugin that Orca used up until now will continue to allow getting information from the printer, including presumably AMS information. It just no longer allows for control/heating/sending prints - that's now what the Connect app is for. |
|
Will this affect the Calibration tab as well? As in, will we be able to run Bambu calibrations as before? |
|
I'm not a security expert but why would you store a private key inside Bambu Connect application? |
|
Should be checked if those changes to some core network functionality does interfere with other non bambu printers or if data from those machines can get leaked to bambu with those changes. |
|
@lanewei120 thanks for your effort but I hope that this will not get merged.
Bambu Connect is evil.
We need the same access that is in Bambu Studio. And support for Developer Mode. But not Bambu Connect. |
Yes. Please.. If they can do it through the Bambu studio directly to the printer why not does Orca Slicer ?? |
This is exacly what the response should be. Reject the PR. and implement the new dev mode with NICE wiki gifs how to do so... that is the best response/slap in the face they should get. This pr is just a go eat dump while we kill your xxxx action.. there is no war in ba sing say. |
|
@lanewei120 I’m just going to say what most non bambu employees are probably thinking : This change is gross and should be rejected out of hand . Orca should be able to continue calling the plugin directly. If Bambu puts binary caller checks in the way , Orca or someone else can just patch the libraries with a delta file to remove the checks trivially (and legally) . This change is a Trojan horse to cripple orca and should not be accepted . Bambu’s approach here is technically broken and is utterly impossible to defend from a security perspective. You cannot protect this authorization scheme from compromise because , fundamentally the slicer is running on untrusted computers . There is therefore no real additional security in using Bambu Connect at all. There’s zero plausible reason Bambu Slicer can use the plugin “safely” and orca cannot. You need to go back to the drawing board , this “feature” adds nothing but pain for Orca users for no benefit . Someone needs to have the balls to tell Dr Tao and whoever else mandated this approach that this just isn’t going to work, and you’re only alienating customers and the community . |
|
@lanewei120 This PR downloads the new plug which requires the slicer to be digitally signed to control the X1C even with the old firmware. So in effect if this is implemented as-is, it would force all users to upgrade to the latest firmware, which contrary to what Bambu has said, should be allowed to continue to work. This PR So I am sorry but at best this is an draft PR that needs (a lot) of further work to continue providing backwards compatibility as promised by Bambu... The same printer with the existing Orca code base and "legacy" bambu network plug in:
Come on Bambu! If you'll raise a PR at least make it compatible with what you've promised will continue to work... |
|
Anyone want to pitch in to the fund to rent a sick linux fund and decompile the bambu network plugin? |
|
Even worse is that with their latest network plugin/official software the "bind LAN mode printers with IP directly" is still broken. See issues like TBH I wouldn't put too much faith in cybersecurity for a company that couldn't figure out such basic network problem. |
@igiannakas |
You can fix it by just leaving the plugin alone and not doing all this silly performative extra protections stuff. The community and your customers hate this, and it adds no security. If you feel you have to pack your new DLL with a breakable DRM /code obfuscation scheme (virbox, yes people have figured this out already) .. you’re doing community integrations wrong . The correct fix is a policy change/revision. |
|
Thank you everyone for your valuable feedback. We encourage Bambulab to reconsider their current policy. Users should have full control and choice over the hardware they've purchased with their hard-earned money. Meanwhile, for current Bambu printer users, we advise NOT upgrading their firmware and to keep their printers in LAN-only mode for security reasons. In the meantime, we will continue focusing our own development efforts on features and improvements that deliver real value to the community. |
Gigachad move, thank you for this decision! |
I'm sure part of the plan moving forward is to try to force the issue with the tools that won't be compatible, therefore making it required by all users. I'm happy that @SoftFever isn't playing that game with them. |
|
I have spent way too many hours thinking about this, but I think I have a formulation of concerns the community has that is hopefully useful to Bambu that helps them appreciate why users and the Orca community is so frustrated here:
|
|
I think this decision is not good at all. Okay, I get that most are not fine with the way Bambu is going here. But just not make Orca work directly with it will make it worse for all. And simple support the url schema doesn't hurt, it just splits the community further. I'm quite certain that in a few days, we have the first forks of Orca, don't changing anything, just adding support for Bambu connect. Because it's just easily done. There is no win on all sides. But for me it just looks like you want to throw users under the bus for forcing your own agenda, just as Bambu does. Discussions are fine and needed, but in my eyes you are now acting similar. |
I disagree strongly with this sentiment. If it's easily done, you are welcome to do it in a post-processing script or separate app, which is the easiest route because it would be at the end of G-Code generation. I highly doubt people will fork Orca just for this purpose. OrcaSlicer isn't throwing anyone under the bus. The hostile change is coming from Bambu, and it would make using OrcaSlicer worse for everyone who wants to stay on old firmware / X1+, unless OrcaSlicer implemented both this Bambu Connect scheme and the existing way. |
Thanks for your reply. I respect that opinion and it's good to have different views on that. But the last part basically sums up the point I had. Trying to force Bambu to implement it how you like it and if not you don't integrate neither one of the ways. That's making it worse for all for the sake of getting your will. And that's what I meant, it's the same acting as Bambu did. I really understand that the changes Bambu made are upsetting for some/many. But others may not be so critical and would just like a simple button to send it to Bambu connect and move on ... |
if you really insist on embracing the bambu way of doing things, i suggest you just use bambu studio. |
|
@dewi-ny-je It seems like you've misunderstood this whole ordeal. There is nothing wrong with OrcaSlicer. You can export your GCode and upload it via Bambu Connect or SD Card. It's Bambu Lab who decided to deny these features from OrcaSlicer while their own slicer, BambuStudio, will continue to work. |
Yes. And these users will hopefully do the reasonable thing and complain to BL about it, who are the ones who have caused this problem. |
Never said it wasnt. I said that this decision seems to me to not be rooted in ideology, but in what SoftFever sees as a poor solution from BL. |
Sorry, didn't wanted to look like reacting to your comment, quoted your comment as I agree with it and wanted to "add" my 2 cents to it in reaction to dewi-ny-je. |
|
To clarify a few things from my understanding of the situation. All views below are my own and based on my own understanding of the code, what has been proposed and the blog posts. If Bambus announcement is valid, with the new firmware in Dev LAN mode the existing plug in and method ought to work. No need to bake in a new, second plug in to support both old and new firmware. From what I understand no one has tested this, ie does it work with existing plug in or is the new one needed, myself included, as the dev lan mode is not released yet, but I may be wrong. If the users want cloud access too with the new firmware, exporting as gcode and dragging and dropping to Bambu connect is the option right now. There they can do filament mapping to the file and control the printer. For existing users, the recommendation to remain on the old firmware stands. We simply don’t know what will be and not be allowed and how orca will interact with the new firmware or what the final workflow is. So best to stay in the current firmware at least until all these points are clear and code is out in its final form. So personally I think Softfever's approach is the right one - integrating a new plug in, that as it stands today, breaks old firmware, or supporting two plug ins with significant code rewrite is not the way to go. Neither is trying to identify what the bug in this Pr is, when we have very limited information on how the closed source network plug in works. Orca is not a company, so development time is precious, and, at least personally as a contributor, I would rather focus efforts on things that make print quality better! Also neither removing the freedom of choice from the users is the right thing to do and it should not be supported. It’s not OK to accept that in the name of “security”. The security of the users LAN is the users responsibility, not Bambus. So Bambu must not place restrictions there. It’s literally our problem if our home network is hacked! Also why the heck does bambu refuse support if the users enable dev LAN mode? There is literally zero reason to do so. That is why, this is not OK. Why should a company need access to your print files and for you to use their inherently insecure integration to provide you with support? Why would your camera feed need to be streamed to a datacenter somewhere to reach your app when you're on the same lan? WebRTC and RTSP feeds can work locally, with even better security and user experience. Why is it needed to have a middle man here? Again, this is a solved-for problem. The bambu app can check for P2P connection to the camera using WebRTC and RTSP. If a user wants remote access to their LAN only printer they can choose their own solution (eg Tailscale) to access their LAN or use Bambu's relays. Again, this is a solved problem. Same as the users freedom to choose how they operate their printer. Bambu really ought to do better here, implementing heavy restrictions like these in the name of security, when the Bambu connect code has already been reverse engineered and the keys made publicly available is not the way to go. How is that more secure? There are much better ways to implement enhanced security. For example; start with cloud opt in, not opt out! LAN mode must be fully functional - so allow full features in the app in LAN mode. What is stopping Bambu from doing that? Mobileraker already does that with klipper! Also having Bambu owning the private key to all printers is inherently insecure. Have we forgotten how Bambu cloud initiated at random prints overnight for a whole heap of users just a year ago? https://blog.bambulab.com/update-for-cloud-downtime/ All in all, there is a need for the dust to settle and see what will be supported vs. not, and tested accordingly. Also Bambu really needs to reflect what sort of experience they want to provide. They can offer a super friendly user experience as they do today but without indulging themselves in extreme control, which quite frankly doesn’t work for the 3D printing community nor is it good for the users that treat the printer as an appliance. Even from a fundamental security standpoint, there are much much better ways to implement true security. So bottom line, right now we dont have working code for the new plug in neither the latest firmware revision that allows dev lan mode. Nor the final Bambu connect application. Nor the proposed approach by Bambu is inherently better. |
|
I may missed it, but if I'm right, the current plugin wont work after the certificate expires... The only way to update the certificate is thought online connection with the cloud or manually by sdcard. Also the plugin itself may need to be updated (uncertain if BL will do this forever). I assume there are legal reasons why this plugin is not part of orca and is downloaded from BL. I think this is also the case for BS itself. |
It's literally unknown what will happen. The amount of information available is just the two blog posts, which can (and have been) edited at any time. So we have to wait and see. Hence do not update and wait until the dust settles. Bambu has to do better here. Their chosen approach is not only "wrong" from a 3D printing user community which is fundamentally built on FOSS, but also from a pure security stand point which contradicts the "security" claims made. I dont want to draw conclusions as to what is the motive behind this, but bottom line, Bambu needs to go back to first principles:
Basically make yourself compelling as a complete offering while respecting the needs of your power users! Simple as that. You don't need to go out of your way to lock down advanced users out of your product in the name of false security. This is the most vocal group and they can be your advocates. So why go after them? |
It's built on FOSS, sure, but most of the users don't even know what FOSS or a firmware is, very likely. |
Indeed users dont care. But I come back to my points above -
And respect your brand advocates - power users are your best marketing. Also the new approach is inherently insecure (handling of private keys). Please dont forget this incident here: https://blog.bambulab.com/update-for-cloud-downtime/ Their design choices are inherently insecure. Which will come back and bite end users that don't care about all this, when/if there is a cloud breach. Bambu can and should do better - this is a solved for problem industry wide. Also end users will care if further lock down to their platforms happen. While I get and respect Slant3D's opinion, there are much better ways to handle this without alienating your advocates and offering a truly better product for the benefit of all - more secure, open and so forth. |
The users that don't know and don't care also don't use Orca Slicer - or even know that it exists. They use Bambu Studio. They're unaffected by everything going on here. Why do you keep dragging them into this when they're irrelevant to the question at hand? And seeing as how you all obviously don't mind jumping through the extra hoops that the whole Connect workflow already inherently requires, why don't you just associate Bambu Connect with the .gcode.3mf file extension and send them through your file manager? It's just another extra click, why does it suddenly matter now when the first half a dozen weren't the slightest bit inconvenient before? |
This PR ported the following changes based on BBS 1.10.1 codebase: - The ability of binding printers via IP (Fix #8099) - The ability of setting AMS filaments during print (Fix #7882) - Some other related fixes and improvements Thanks BambuLab for those improvements! ~~Please note: with this update, we will no longer be able to streaming the live camera through cloud, only through Lan (even if the printer is not in Lan mode). At least that's what I saw with this PR and also #8103, more tests & feedbacks on this are needed.~~ Update: nvm, I missed a commit that fixes the remote live view. It's working now. Unfortunately even with this update you still cannot bind the printer in a different subnet, which is an inherent problem from BBS: bambulab/BambuStudio#4512 bambulab/BambuStudio#5070 bambulab/BambuStudio#5833 and more...
|
Bambulab has released New FW 01.08.05.00 for the X1 series, as explained in the release note. This version officially implements Third-party Integration control. I’m wondering if anyone has verified this? Will it affect the use of Orca Slicer? https://bambulab.com/en-us/support/firmware-download/x1 |
|
That's the point - we don't want a need for software talking to our printers to be "official or authorized". It is not the manufacturer who should decide which software is "authorized". In simple words: After Bambu Lab sells the printer, it is the printer of the buyer. The buyer is the one who decides what is "authorized". Not Bambu Lab! |
|
Agree, but still... we may want to verify if the LAN only with new developer mode at least works the same as LAN mode previously. Currently in the mid of some prints that have to be done, but can test it probably at the weekend if nobody else has done it till then. |
As a user, I do mind jumping through extra hoops, and I do mind performative "security" features that do nothing other than get in my way and add no actual security. As I customer I do deeply resent a company changing the terms of use AFTER the sale of the product. Lastly, as a user I don't want to have to use a "blessed" piece of software to control the thing I bought. This artificial restriction is like HP saying you can only use their ink, or a car company saying you can only put their tires on your car, or the electric company telling you what bulbs you are allowed to use. If you cannot see the core issue with this type of thing, this conversation is not for you, I guess. But a lot of us do care about the freedom to use our paper with "unapproved pencils". If you're unhappy with Orcaslicer doing this, remember: it's not Orcaslicer who said "no", it's Bambu who said, you must use our approved pencils to write on the paper, and nobody else's. Direct your frustration at them, not at someone who makes a better pencil than Bambu does. Bambu's closed attitude is why we can't have nice things. Ironically, as a GCODE generator and sender that literally tells a printer "where to draw", a slicer is very much like a pencil control mechanism of sorts. This is the best clear cut analog I can come up with that illustrates the ludicrous position some people are taking in excusing Bambu's restrictions and blaming anyone but Bambu. Don't blame the victim, blame the perpetrator. |
|
Hey @lanewei120 - who one ought to contact within BambuLab to explain them that "Bambu Connect" is really bad idea and to scrap that whole homebaked "security" measure and instead use more secure industry standard way? The potential benefits are enormous: actual secure communication instead of some electron-based middleware, actually seamless printer operation from orca, no community blowback, use of improvements from orca for advanced users... |
An aside: They're unlikely to listen, as this appears to be the core thing enabling some printer-farm and platform monetization strategy they appear to be inching towards (see the release of their platform SDK and local-kinda servers that need to phone home in their wiki articles). This is sadly typical of enshittification of a once-great thing. First they screw the small customers, then the business customers to extract more value for the shareholders. It's hard to see the current behavior trends and not draw parallels with most other tech company monetization playbooks. I'd like to believe it's not true.. but.. if it looks like a duck and it quacks like a duck... |
dev mode upuntil now, it looks to be better than previous lan mode, more stable but that's just 24hrs of usage from me.
I don't think that Bambu would do that (to lock in filaments or farm management) because competitions do exist and they're not far behind. Some of them even do better than Bambu, like the Creality K2P is really solid and has earned much of reputation. The security thing, is real though we don't like the way they enforced it. So there have been a couple fire accidents with 3D printers recently, and it's not too hard to burn your house down with a hacked 3d printer. |
I didn't see a reply to this. Is it safe to assume that 01.08.05.00 and the new 01.09.00.00 firmware will break Orca's direct integration? |
|
bambulab/BambuStudio#6726 |
| @@ -78,6 +79,7 @@ namespace BBL { | |||
| #define BAMBU_NETWORK_ERR_PRINT_SP_PATCH_PROJECT_FAILED -3110 //failed to patch project | |||
| #define BAMBU_NETWORK_ERR_PRINT_SP_POST_TASK_FAILED -3120 //failed to post task | |||
| #define BAMBU_NETWORK_ERR_PRINT_SP_WAIT_PRINTER_FAILED -3130 //failed to wait the ack from printer | |||
| #define BAMBU_NETOWRK_ERR_PRINT_SP_ENC_FLAG_NOT_READY -3140 //failed to get flag info | |||
This needs more visibility. Maybe a separate issue pinned. That’s outrageous to be honest |
@Noisyfox Is this still the case? It shouldn't be too difficult to do some runtime instrumentation to patch out the debugger checks with https://github.com/frida/frida-gum. |
So a working send to printer ist not "meaningful value" for users with new firmware? Just add it for new versions and stop bitching around (both sides). Thanks |
You are the one who's bitching around. The Orca community owes you nothing. I have quite some opinions against current status of Orca but your use of language is just low and unacceptable. |
Please take your entitlement elsewhere , it is not welcome here . These people work very hard for mostly free and are doing their best with the hand they’ve been dealt. |
|
For anyone who wants to send a sliced print from OrcaSlicer can download Bambu Connect here: Bambu team wants / wanted to add a button that makes Bambu Connect app window appear. It's not needed for the operation, it's just a shortcut. |
Description
support
Screenshots/Recordings/Graphs
Tests
tested the slicing+printing+device page
mainly for Orca's Reference,
no need to merge