GHSA-v8f6-5mx7-9fff: 
Rust vulnerability analysis and mitigation

Fixed in 0.2.0-preview.10; upgrade to it.

Impact

Where Kule looks inside a task's connection (to fill in secrets, or to keep a registry read-only), it answers some requests itself and never sends them on: a write to a read-only registry, a credential Kule does not hold for the host, a body it cannot check whole, a request it cannot read one way only. Kule refused those requests, but the connection was logged in the task's network.jsonl as tunneled, with no reason, and the CLI's net: lines and the app's Timeline showed it as one that went through. A connection that ended in an error of its own was logged the same way, and on plain HTTP as cut by Kule.

Fix

Such a connection is logged as cut, with why in Kule's own words (Kule refused a request in it: …), never the request's content. A connection that ends in an error of its own is logged as failed, with why, for plain HTTP too.

Tests

a_refused_request_ends_its_tunnel_saying_why, secrets_used_before_an_error_are_still_told, a_tunnel_kule_looked_into_is_logged_as_what_became_of_it, a_plain_connection_is_logged_as_cut_by_kule_or_failed_on_its_own (kule-engine).

Workaround

Upgrade to 0.2.0-preview.10. The refusals themselves held; only their record was wrong.