Graham McIntire
33e2ccf51a
- giro_client: remove verify: :verify_none, default to OTP :verify_peer - map_live: validate recovered_band against BandConfig and recovered_time against time_in_window?/2 to prevent stale-state breakage - prom_ex: local fork of Plugins.Phoenix that normalizes transport tag values to prevent telemetry_metrics_prometheus_core dropping series
3.3 KiB
Bugs found
1. High — GIRO HTTPS requests do not authenticate the server
Microwaveprop.Ionosphere.GiroClient.default_req_options/0 sets verify: :verify_none for every production request (lib/microwaveprop/ionosphere/giro_client.ex:197-217). That disables certificate and hostname verification. Anyone able to intercept the connection can substitute ionosonde data while the application treats the response as genuine. The fact that the feed is public/read-only does not remove the integrity requirement: forged measurements can alter propagation predictions.
Use a verified TLS connection. If the origin's certificate chain is incompatible with the current OTP client, use a different verified origin/proxy, supply a correct CA chain, or fail closed until the origin is fixed; do not silently disable verification.
2. Medium — recovered map state bypasses the validity checks applied to URL state
The map restores selected_band and selected_time from LiveStash (lib/microwaveprop_web/live/map_live.ex:49-66). In resolve_view/4, a recovered band is accepted without checking it against BandConfig, and in resolve_time/3 a recovered time is used directly whenever the URL has no valid t parameter (lib/microwaveprop_web/live/map_live.ex:171-188). By contrast, URL times are checked against the currently available forecast window.
After forecasts age out, a returning/reconnecting user can therefore be restored to a time for which no score file exists. A band removed or renamed in configuration can likewise remain selected even though it is no longer offered by the UI. The page then requests missing data and can render an empty/broken map until the user manually changes the selection.
Validate recovered bands against the current configured bands and validate recovered times with time_in_window?/2; fall back to the default band/current cursor when either value is stale.
3. Medium — Phoenix socket/channel Prometheus series are discarded
Microwaveprop.PromEx enables the built-in Phoenix plugin for socket and channel metrics (lib/microwaveprop/prom_ex.ex:26-35). During the full test suite, every LiveView socket/channel event repeatedly logged:
Dropping aggregation for bad tag value. metric:=[:microwaveprop, :prom_ex, :phoenix, :socket, :connected, :duration, :milliseconds] tag: :transport
Dropping aggregation for bad tag value. metric:=[:microwaveprop, :prom_ex, :phoenix, :channel, :joined, :total] tag: :transport
The installed PromEx Phoenix plugin passes Phoenix's transport metadata through as a label, while the Prometheus aggregator deletes a series when a label value does not implement String.Chars. Consequently the advertised socket connection and channel join metrics are absent precisely when LiveView traffic occurs, leaving dashboards and alerts blind to those paths.
Override/patch the Phoenix metric tag mapping to normalize transport values to a bounded string (for example the transport module name), or update to a compatible PromEx release. Add a metrics test that opens a LiveView connection, scrapes /metrics, and asserts that the socket/channel series is present without a dropped-aggregation warning.
Verification notes
mix test completed successfully with 4,065 passing tests and 6 skipped. These findings are boundary, security, and observability failures not represented by a currently failing assertion.