octoturge
a77e93940f
id in printers.toml is just a label you chose for config purposes - nothing ties it to a specific physical printer, and renaming it (or reusing it for a different unit down the line) would silently break the pin lookup and re-trigger trust-on-first-connect for hardware that was already trusted. The serial number is the one thing about a printer that can't change, so that's what a pin should be keyed by: certs/pinned/<sn>.pem instead of certs/pinned/<id>.pem. Verified against a real TLS server: pinned a printer under one id, renamed it in printers.toml with the sn left unchanged, and confirmed the second run found the existing pin silently (no re-TOFU) rather than re-pinning.
35 lines
1.2 KiB
Rust
35 lines
1.2 KiB
Rust
//! Run with: cargo run --example auto_connect_bambu
|
|
//!
|
|
//! The "smooth, no manual steps" version of test_bambu_certs +
|
|
//! fetch_bambu_cert combined: for each Bambu printer in printers.toml,
|
|
//! makes sure it has a working certificate, auto-pinning one via
|
|
//! trust-on-first-connect if the bundled CA doesn't verify. Safe to run
|
|
//! repeatedly — a printer that's already pinned (certs/pinned/<serial
|
|
//! number>.pem) just gets re-verified against its pin, no network trust
|
|
//! decision is made again.
|
|
|
|
use continuum_proxy::fleet;
|
|
use continuum_proxy::printer::PrinterHandle;
|
|
|
|
fn main() -> anyhow::Result<()> {
|
|
let mut printers = fleet::load(std::path::Path::new("printers.toml"))?;
|
|
let cert_dir = std::path::Path::new("certs/pinned");
|
|
|
|
for printer in &mut printers {
|
|
match printer {
|
|
PrinterHandle::BambuV1(bambu) => report(&bambu.ensure_trusted(cert_dir)),
|
|
PrinterHandle::BambuV2(bambu) => report(&bambu.ensure_trusted(cert_dir)),
|
|
_ => {}
|
|
}
|
|
}
|
|
|
|
Ok(())
|
|
}
|
|
|
|
fn report(result: &anyhow::Result<()>) {
|
|
match result {
|
|
Ok(()) => println!("connected"),
|
|
Err(err) => println!("failed: {err}"),
|
|
}
|
|
}
|