Thank you both very much Robie and Seth :) > I think we still need to make a policy decision on the plugin packaging question
Indeed... here's my thinking :) *Biiiig caveat up front* everything below is my own read of the code and my recommendations off the back of it - I still need to run it past Google before I can commit to any of it (especially the "disable by default" idea and the telemetry bits). So treat this as "here's where I think we should land and why" for now... Digging into the config plumbing more actually makes the case stronger than I realised at first, there's actually 3 independent toggles here not just the 1. I'd initially assumed the only off switch was the `acs_client`, which is the sledgehammer that would also kill Google's telemetry/inventory (hence my earlier reluctance about Google ever agreeing to it). But the agent separates it out a bit: * `enable_local_plugins` - the packaged core plugin (the agent's actual functionality) stays on * `on_demand_plugins` - the dynamic/external ACS-fetched plugins (i.e. the archive-bypass channel you're worried about) * `acs_client` - the ACS subsystem `on_demand_plugins = false` disables the dynamic-plugin channel more "surgically" (it gates the ACS watcher that carries the install requests). And, the bit that I think unblocks all our concerns, outbound telemetry and inventory _push_ are not gated by that watcher, they're sent independently (gated only by `metric_collection_enabled`/`acs_client`). So we can turn _off_ the external-plugin channel _and_ keep Google's outbound telemetry/inventory data intact. (Disabling `on_demand_plugins` does also switch off the control plane's inbound _queries_ over ACS i.e. GetAgentInfo/GetOSInfo/ListPluginStates - but that's exactly the channel we're trying to close, and the precise impact of that is one of the things I'll confirm with Google). That removes what I expected to be Google's main objection (but I still want/need to take it all to them...) So, I'm feeling: * Option 0 as the default - ship `on_demand_plugins = false`. It's a one line change to an upstream-supported toggle (i.e. no delta for us to carry), the archive-reviewed core plugin keeps working and Google keeps their telemetry. It also creates a more "honest" story for us: "Ubuntu ships the reviewed agent and core plugin, keeping the out-of-band plugin channel opt-in to users" * Option 1 as a later escalation (not a competing choice) - really it's just "Option 0 plus we packaged plugin xyz" for any specific plugin that ever earns archive review. The handler already refuses to let the control plane reconfigure local/packaged plugins so those are protected. No need for us to decide on 0 vs 1 right now IMO * Option 2: I agree we should avoid this. Beyond your source- availability objection it's actually worse than it looks xD There's no reviewed hash allowlist mechanism today (the current checksum is supplied by the control plane per-request, not pinned by us) so we'd be writing and carrying new security-critical enforcement code as a delta, and every Google plugin revision bump would need a re-review _and_ an archive update/SRU each time. IMO this is the worst option on principle, maintenance and attack surface... booo On your (Robie's) "default means overridable, undecided whether via userdata": the code already answers half of it. These toggles are read only from on-disk `/etc` config, with no metadata/userdata path to set them. So "`/etc`only override" is the current behaviour and costs us nothing (i.e. a userdata override would be new code) If all this lines up with your thinking Robie and Seth, I'll take "Option 0 by default, `/etc` only override, keeps telemetry" to Google and see if they're cool with it. Still happy to walk through any of the config specifics if useful though ofc! Cheers! :) -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/2164943 Title: [SRU][FFE] Please update to version 20260819.00 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/google-guest-agent/+bug/2164943/+subscriptions -- ubuntu-bugs mailing list [email protected] https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
