AlinsRan commented on PR #13756:
URL: https://github.com/apache/apisix/pull/13756#issuecomment-5176386607
Both addressed in ea542caa8, and the first one turned out to hide a bigger
problem.
**[P1]** You are right that skipping is the wrong handling, and while fixing
it I found the feature did not work at all. `apisix/cli/schema.lua` pins every
keyring entry to exactly 16 characters:
```lua
items = { type = "string", minLength = 16, maxLength = 16 }
```
`apisix start` runs `schema.validate()` and `util.die()`s on failure, so a
32-byte key in `config.yaml` never reached `init_iv_tbl` — APISIX just refused
to start. My PR description claiming no schema change was needed was wrong.
So the fix is now on both levels you suggested:
- schema: a keyring entry must be 16 or 32 characters, anything else fails
startup;
- `init_iv_tbl`: an unsupported length is logged as an error instead of
being dropped silently, for the paths that do not go through the CLI schema.
The reason CI was green is that all four tests called `init_iv_tbl` directly
and bypassed config validation. Added `t/cli/test_main.sh` cases that run the
keyring through the schema (32-byte accepted, 20-byte rejected) plus a block
that reads the keyring from `config.yaml`. Verified the new t/cli case is
discriminating: with the old schema the 32-byte keyring fails with `failed to
validate config: ... property "keyring" validation failed`.
**[P2]** Rewritten. TEST 3 now encrypts with a keyring holding only the
16-byte key, then decrypts that ciphertext with `{32_byte_key, 16_byte_key}`
and checks new writes go through the AES-256 key.
Also updated `conf/config.yaml.example` and the en/zh `plugin-develop.md`,
which still documented the keyring as 16 characters / AES-128 only.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
