bootimus reaches out to a remote source on container start to refresh the distro profiles (35 entries) and reports back via log lines:
Profiles: Remote update complete (version: 0.1.72, added: 0, updated: 35)
Admin: Distro profiles updated from remote (version: 0.1.72, added: 0, updated: 35)
The flag --disable-remote-profiles exists per bootimus --help, so the maintainer thought about it. But:
- The behavior isn't disclosed in the README or any of the
docs/en/ pages I read.
- It's opt-out, not opt-in. New users have no chance to consent before the first call goes out.
- Implications: availability dependency (offline starts may misbehave or block), data leakage angle (the upstream URL gets pinged from every bootimus instance on every container start — sysinfo-shaped telemetry whether or not it's intended).
Suggested:
(a) Document the behavior explicitly in docs/en/ (deployment.md or a new privacy/telemetry page) with the exact upstream URL bootimus contacts, and reference --disable-remote-profiles in the same place.
(b) Optional: change the default to disabled and require opt-in via env/flag. Less convenient but matches the principal of least surprise for self-hosters who picked an Apache-2.0 self-hosted tool partly to avoid phone-home behavior.
Even just (a) closes the disclosure gap.
bootimus reaches out to a remote source on container start to refresh the distro profiles (35 entries) and reports back via log lines:
The flag
--disable-remote-profilesexists perbootimus --help, so the maintainer thought about it. But:docs/en/pages I read.Suggested:
(a) Document the behavior explicitly in
docs/en/(deployment.md or a new privacy/telemetry page) with the exact upstream URL bootimus contacts, and reference--disable-remote-profilesin the same place.(b) Optional: change the default to disabled and require opt-in via env/flag. Less convenient but matches the principal of least surprise for self-hosters who picked an Apache-2.0 self-hosted tool partly to avoid phone-home behavior.
Even just (a) closes the disclosure gap.