Pull requests / #569

#569 serve, setup: an empty API key is refused from the config file and from setup's --api-key (#213)

closed · @gputier · 0 comentários · No GitHub

Setup & installServer & APIAMD / HIPSecurityLinux

Descrição

#213 already refuses an explicitly empty key given as `--api-key ""` or as an empty `STRATA_API_KEY` (serve/server.py:2750-2756, commit 4d25c61). Two other ways to give a key are still open on v0.1.37, and both end with a server that runs without authentication and says nothing about it.

I ran serve.server.main() with the mock engine on an unmodified v0.1.37 and tried every way to give a key. These are refused with exit code 2: `--api-key ""`, `--api-key "  "`, `--api-key=`, `STRATA_API_KEY=""` and `STRATA_API_KEY="  "`. Abbreviations such as `--api=` are not a way in, argparse rejects them as ambiguous with `--api-monitor`. The two that start the server:

1. `"api_key": ""` in the config file. The service gets the key "" and authentication is off (serve/server.py:2756, `svc.api_key = a.api_key or cfg.get("api_key", "")`). `"api_key": null` behaves the same. `"api_key": 123` starts too, with an integer as the key. `"api_key": "   "` starts with a key made of spaces.
2. `setup.py --api-key ""`. On an install, `if a.api_key:` (setup.py:3557) drops it, so no key is saved. On a start, `keep={"api_key": a.api_key, ...}` (setup.py:2968-2984) only filters out `None`, so `start()` writes "" into the config (setup.py:2588-2590), over an existing key if there was one, and the server then runs without one (case 1).

The fix is two checks. serve/server.py refuses a config `api_key` that is not a non-blank string, right after the config is read and before the engine loads, with the same kind of message as #213. setup.py refuses a blank `--api-key` with `ap.error`, next to the other argument checks. I left the existing argv check alone, it works.

Tests: 7 new ones, 5 in serve/test_server.py (`EmptyApiKey`) and 2 in tools/test_setup_choices.py (`ApiKey`). `test_empty_key_in_the_config_refused` and `test_an_empty_key_is_refused` fail on v0.1.37 without the change (the server starts with key "", setup exits 0). The other five pass before and after and pin what already works: empty argument, empty variable, a key from each of the three sources, and no key at all still starting.

Side effect: a config that already holds `"api_key": ""` (written by the setup path above, or by hand) now refuses to start, with a message that names the key. Before, it started without authentication.

I ran the Python suite in a python:3.12-slim container: 422 passed, 47 failed, and the same 47 fail on a clean v0.1.37. They are not related to this change. On Linux `setup.EXE` is "strata" (setup.py:191), so `normalize()` in tools/test_setup_golden.py:58 also rewrites the start of the log file name, which breaks the golden comparison, and `test_prebuilt_hip_zip` expects `strata.exe`. With `EXE` forced to "strata.exe" the whole suite passes (checked on the other branch: 417 passed, 0 failed). I did not touch it here.

No site

Links install, modelos, releases.