hWuxH

Other company, same shitty anti-user, anti modding, anti open source mentality and security theater. Nah.

Still no valid argument because there's always the possibility of a lookalike fake banking app that intercepts your credentials and logs in on another device that passes integrity checks.

Its not only a licensing issue, but they abuse this closed source binary to lock away major features from other slicers (DRM, signature checks), hinder development, include anti-debugging, telemetry, encrypt logs and configs, etc.

And the stock plugin ships an unaligned atomic that triggers the kernel's split_lock detector on every modern Intel CPU. Startup stalls for 25-60 seconds while the kernel walks each trap; every Device-tab click hits it again. The workaround (sysctl kernel.split_lock_mitigate=0) degrades system-wide performance and still misbehaves in LAN-only mode. Reported to Bambu over a year ago and still open: bambulab/BambuStudio#8605.

And no ARM or non-x86_64 build

Why are you too stupid to get that the moment software binaries for the slicer are distributed is when they have to ship source code? Next time read the AGPL instead of making smartass assumptions. When the printer hardware is released "to the general public" or "backers" is entirely irrelevant...

* 2022-05-23: KickStarter launch, distributing Bambu Studio binaries to every backer, reviewer and influencer *without source code*. They also sanitized the About dialog and removed any open-source attributions, AGPL disclosures, or links to the underlying PrusaSlicer/Slic3r code. [https://www.reddit.com/r/BambuLab/comments/vnzpie/comment/ie...](https://www.reddit.com/r/BambuLab/comments/vnzpie/comment/ie...)

* 2022-05-29: Admitted it's based on PrusaSlicer [https://blog.bambulab.com/to-open-or-not-to-open-that-is-the...](https://blog.bambulab.com/to-open-or-not-to-open-that-is-the...) * "We would like to ask for the understanding of the community to give us some time *before we open-source* Parts 1 and 2, which is scheduled for the second half of this year." - admitted it's currently an AGPL violation

* 2022-06-29: Evidence. "GPL requires release of source the moment binaries are out. Many people have had the binaries for weeks. They are 100% in violation". [https://x.com/DreadMakerAdam/status/1542216014984876036](https://x.com/DreadMakerAdam/status/1542216014984876036)

* ???

* 2022-07-15: They only dumped it (with prior git history squashed) onto GitHub months after the initial release, after immense community pressure. [https://www.reddit.com/r/OpenBambu/comments/1thfslw/comment/...](https://www.reddit.com/r/OpenBambu/comments/1thfslw/comment/...) [https://github.com/bambulab/BambuStudio/issues/1](https://github.com/bambulab/BambuStudio/issues/1)

it literally makes no difference for the bambustsudio program you download. GPL has the same corresponding source clause

What's the threat model where not storing them all at once provides any benefit? If someone has admin it's already game over. Can just hook the browser to retrieve all passwords on demand.

If passwords are fetched remotely on-demand, you steal the account API key from memory. If they're encrypted, you steal the master password or decryption key. ... So what's your solution?

> What if this is not about closing off an API. Maintaining a stable API is difficult

That's why any sane software uses a stable public API and an internal one that can be closed off or has breaking changes all the time.

> MQTT has no versioning and limited hierarchy in the pub / sub model

It's currently handled like this: https://github.com/Doridian/OpenBambuAPI/blob/main/mqtt.md. Would it be a far stretch to add an "api_version":x field and a "internal_" prefix for some commands?

I wouldn't call it more or less secure. You're just on your own and should expect this (internal) API to have breaking changes at any time.

> Right now, the printer's local MQTT server can only be accessed from the local IP using an 8 digit password obtained through through the physical display.

The problem is hackers don't need to play by the rules (accessing the display).

8 digits that never change is a joke in terms of security, it could be brute-forced within hours/days by sending a network request for each possible combination.

mitm: afaik Bambu Studio/Connect/Handy validate the printer's certificate during the TLS handshake, but most third party software probably doesn't (barely found documentation about it).

And there are a few other (although not as fundamental) weaknesses like no mutual authentication, access control or revocation of specific clients. Due to the nature of MQTT, every client can see messages sent by other clients once authenticated.

Everything was sent in plaintext early on. But since 2022/2023 it's TLS: https://wiki.bambulab.com/en/security-incidents-cloud-traffi...

ppl always get caught up on the x509. They're actually a good thing and are absolutely necessary to prevent mitm since they use self-signed certs. BambuStudio also works that way.

The issue is introducing further measures which don't provide any security benefit to the user (can be spoofed): only allowing critical commands from BambuConnect.

> Username/password over TLS would do that better than what Bambu Lab is proposing

Already works that way and isn't affected by this update: https://wiki.bambulab.com/en/security-incidents-cloud-traffi..., https://github.com/Doridian/OpenBambuAPI/blob/main/mqtt.md#l...

- what the key is used for: signing critical operations, most notably print and gcode commands: https://git.devminer.xyz/archive/bambu-connect/src/commit/47..., list of known MQTT commands: https://github.com/Doridian/OpenBambuAPI/blob/main/mqtt.md

- what the firmware does: verify these operations, meaning it can reject MQTT messages with an invalid/missing signature from third party software

- the big flaw with that approach: by extracting the key, third party software can get full access again

- improvement to security: none (that obfuscation layer doesn't prevent anything if the printer/cloud were vulnerable)

authentication stays the same as before: https://git.devminer.xyz/archive/bambu-connect/src/commit/47...