support bambulab's new security functions #8103
Conversation
verified on 1/19 night
Change-Id: Ifde58610a1db29ba9d87078e605dc556ec0ce148 Signed-off-by: Stone Li <[email protected]>
|
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. |
|
As long as Bambu Connect is closed source, it will likely never be available for less popular operating systems and processor architectures. Hence it should not be relied on at all. Using developer mode is currently imho the least evil. |
That wouldn't matter in reality - "normal" users will run Win/mac/Linux where the app exists, print farms will have a linux server running it or a desktop machine to control their printers. Hobbyists will use dev mode. This all only works if we assume that they are not going to want to lock us into their ecosystem hard, require RFID spool authentication and steal all our data, time will tell. |
|
The point is, they can have closed source firmware all day long but don't force us into closed source apps on our desktops. |
|
I get it, and they don't. |
@zviratko But this is just scaremongering. What BambuLab is proposing wouldn't address this scary-sounding scenario in any way. If malware is running on your PC which is connected to the printer, it's game over. That isn't something they can even dream of protecting against. What would meaningfully improve security is replacing 8 digit PINs with real, strong authentication (think SSH keys), paired with an (optional) requirement that every print has to be physically confirmed on the printer before it starts. I'll copy a suggestion that I made on Discord - not that this is original in any way, just my take on it:
I believe that this would be just as secure as SSH keys, but implemented on top of existing TLS sockets which should make it a relatively simple change, it would maintain compatibility with all 3rd party integrations, and even improve the end-user UX since we wouldn't need to enter the access code anymore. However I'm not a security expert - if anyone sees serious flaws in this approach, I'd love to know. |
You are 100% correct. What Bambu is proposing makes it better, but is not a complete solution. In other words, it IS a bad solution, I just understand why they want to do it... somewhat. (Btw I think Bambu Connect is supposed to contain some sanity checks for the gcode, but let's be honest - it won't work).
The PIN is hex, not just digits. Depending on implementation, it could be enough (password complexity DOES NOT correlate to security if you implement stuff right - google PBKDF2, etc...)
That doesn't solve the crucial problem that the authorized key is present somewhere where it can be misused/stolen/shared on google drive by mistake... And cleaning up unused keys is not as trivial as it might seem if you don't want to anger people. |
In LAN mode, which attack vectors do these proposed changes defend against? If I know or bruteforce your PIN then I can control your printer, otherwise I can't. That's true now and that would remain true with their "improvements".
That's an unreasonable double standard. You said that storing a master key in a publicly downloadable binary "makes security better", but storing a personal private key in a hidden application directory is unacceptable because someone might accidentally share it on google drive somehow? :/
It would just have to be a menu on the printer called "authorized clients" where you could remove them with 1 click. |
The "security" aspect of this update is just nonsense. The fact they store their private keys in the connect app is comically inept. It completely nullifies your last paragraph. The way to secure this properly and conveniently without it having any repercussions on third party interoperability has been solved many times over. |
What risk can you articulate that's resolved by what their pitching?
Being able to manage the credentials would actually be a step forward, I agree, but the fact that it's touchless is one of the selling points here. Your second bit still removes sold value.
While I entirely agree with the point about the difficulty surrounding key management, remember that these printers are designed for laypeople. A mention of passkeys is a quick way to make it difficult for a layperson to use the printer. I love passkeys, they're great... but usability still isn't entirely worked out for the masses. Especially when we're talking about what isn't really a user an/az flow in the traditional sense. |
|
I think this Pull request is becoming a Reddit. With comments not related
direct to code but more personal opinions. Hope the admin close this madness
*Rogerio Dória Loyola-Camorim*
…On Sat, Jan 25, 2025 at 9:14 AM Matthew Kosmoski ***@***.***> wrote:
What Bambu is proposing makes it better, but is not a complete solution.
What risk can you articulate that's resolved by what their pitching?
What would meaningfully improve security is replacing 8 digit PINs with
real, strong authentication (think SSH keys), paired with an (optional)
requirement that every print has to be physically confirmed on the printer
before it starts
Being able to manage the credentials would actually be a step forward, I
agree, but the fact that it's touchless is one of the selling points here.
Your second bit still removes sold value.
That doesn't solve the crucial problem that the authorized key is present
somewhere where it can be misused/stolen/shared on google drive by
mistake... And cleaning up unused keys is not as trivial as it might seem
if you don't want to anger people. Yes, it is analogous to SSH in that
people tend to store their keys insecurely, because there is not (yet) a
userfriendly-enough solution that people can use by default (not talking
about enterprises here), closest would be implementing FIDO *Passkeys*
for SSH.
While I entirely agree with the point about the difficulty surrounding key
management, remember that these printers are designed for laypeople. A
mention of passkeys is a quick way to make it difficult for a layperson to
use the printer. I love passkeys, they're great... but usability still
isn't entirely worked out for the masses. Especially when we're talking
about what isn't really a user an/az flow in the traditional sense.
—
Reply to this email directly, view it on GitHub
<#8103 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAKOW26256GJVI6BF7XM3I32MOS3PAVCNFSM6AAAAABVOZPKOKVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDMMJTHE4TOOBYGM>
.
You are receiving this because you were mentioned.Message ID:
***@***.***>
|
|
I'd like to see Bambu's PR allow for the older/dev method and Connect before this is considered for merging. There is some merit to people want to update their firmware and having the ability to send files over. Of course we will lose some connectivity back but the slicer was always usable in offline mode before. That said the code from in this PR shouldn't force a hard cutover or break existing functionality. That is the rub for me here, if Bambu wants to submit a new BambuConnect style printer profile with all the restrictions fine but it shouldn't break those of us on the Dev or older firmware. |
@psiberfunk When you start to trivialize dev work / effort and say it's easily done then you're wrong out of the gate and taint your entire stance. Were you in the same room while both sides hashed out a path forward? There is more information not being shared here (and maybe anywhere) that has resulted in @SoftFever decision. Dropping support for something that has a large following / user base is not a light decision to make so you should be able to imagine whatever path forward that was proposed in their conversation was not feasible for the 3rd party tooling. Based on my previous experiences with vendors and libraries two reasons why we would turn down an integration is either exponential dev effort to implement / maintain a feature or nueturing your existing features / offerings and only being able to do a limited amount of things your app used to do. It sucks they aren't supporting Bambu printers (I was going to buy another one last week) but maintaining software takes time and open source software is usually financially a net negative for a developer they do on their free time -- so we need to respect that of the Orcaslicer team and their decision. This is a service they offer for free. Hopefully Bambu can alter their decisions and make everyone happier (or at least not as pissed). |
This seems petty politics: you already have a network plugin for Bambu printers which no other printer needs, what's the problem in amending it to upload gcode? no ned to fully control the printer, just gcode upload is fine. Obviously if you don't want to code, don't do it, since it's YOUR time. But your statement sounds like you even won't accept pull requests which extend/update the plugin used to already connect to Bambulab printers, which seems an extremist, fundamentalist position. Don't code it, but don't block it because of personal opinions if someone else is doing the work: as Slant 3D pointed out, the by far large majority of Bambu users doesn't care, they bought Bambu because the wanted the straightforward experience, not because they wanted openness, so by blocking an update of the plugin you are actually the one who does not "provide meaningful value for OrcaSlicer users". I don't have Bambu so I don't care, but I use the plugin to centralise print profiles among various computers. |
It's not only his time, but also his project. He can choose to accept or reject pull requests based on what he finds to be the best solution. In this case, he considers the approach BL is taking to be shit, so he wont add support for it. If you think it should be, I'm sure you can feel free to fork the project and create and maintain your own slicer. It's neither extremist or fundamentalist. He's just refusing to degrade how OrcaSlicer works because BL wants to implement a shitty process. |
Sure, someone will, but technically Orca is also a project of the several contributors which over time contributed to significant parts of the codebase. Maybe even most of it, so a careful evaluation of benefits and cons should be done.
Not clear "degrading" how. Ideology is not an effective way of moving projects forward. Again, I don't care personally, but seeing features rejected this way is not nice to see |
Tons of PR's will get rejected. That's always how it is with open source.
They won't remove the current functionality (the network plugin) unless BL decides to break it (which they very well might). Bambu Connect is not a plugin, but a separate application. It's not comparable at all. SoftFever has explicitly said that he wants to work with BL if they can come up with a solution that works like it does today (which I would guess is something like an actual plugin or an SDK that allows Orca to communicate directly with the printer).
It's not ideology though. It's about what the creator/owner of the project deems the best direction for himself and the users. |
Hopefully Bambu Connect will offer a network interface compatible with Moonraker so that it can receive gcode files. |
Look at the numbers (👍 and 👎) on SoftFever's announcement. As of now 190 to 4 ... and not counting the other positive emojis (more than 100).
Call me wrong, but in my eyes ideology is a huge part of open source. |
|
Most 3d printer users don't even know what a firmware is, and a small fraction of them even knows this repository, so the number of emojis is irrelevant in real words statistics. Anyway my point is there. Discussing further doesn't help much once I brought up my argument which seemed overlooked: real world fraction of users negatively affected, and effort required to accept a third party pull request. As long as I can share profiles among different computers I'm happy, I don't have a BL printer |
|
@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...
Description
support
Screenshots/Recordings/Graphs
Tests
tested the slicing+printing+device page
mainly for Orca's Reference,
no need to merge