>>> [!note] Migrated issue <!-- Drupal.org comment --> <!-- Migrated from issue #3619821. --> Reported by: [rym_oueslati](https://www.drupal.org/user/3684964) >>> <h3 id="summary-problem-motivation">Problem/Motivation</h3> <p>When a key type plugin changes which key input plugin it declares -- the key_value.plugin entry in its @KeyType annotation -- every key that already exists with the previous input is silently given a brand new key value the next time its edit form is saved. A save that changes nothing but the key's label is enough. For a signing or encryption key that means every token, signature or ciphertext produced with the old value stops verifying, with no warning on the form and no confirmation step.</p> <p>Measured on Drupal 11.4.5 / PHP 8.3.14 with Key 8.x-1.22, whose src/Form/KeyFormBase.php is byte-identical to 8.x-1.x HEAD (e0a32405). The key type used was jwt_hs from the JWT module, switched from "text_field" to "generate", with an existing key stored through the Configuration provider. Editing only the key's name gave:</p> <ul> <li>key value sha256 before 57ead58acdaf066b4a990b244208c27c985935aca942a8de13bb0f7f1f53aadb, after 8c77e2263fe69bb6f7d75072da791951657fc56dd07945573b53bc9626ff6383</li> <li>key length before 64 bytes, after 128 bytes -- generateKeyValue() recomputed it from the key type settings</li> <li>stored key_input before "text_field" with configuration [], after "generate" with configuration {"generated":true,"display_once":true}</li> </ul> <p>It happens once per key. After that first save the stored configuration carries generated: TRUE, the form switches to "The key value has already been generated and will not be changed." and later saves are stable. That is not much comfort: the one save that destroys the value is the first one after the module is updated, on every site that already had a key.</p> <p>The origin is KeyFormBase::updateKeyInput(), at line 411 on 8.x-1.x HEAD. Two things compound there.</p> <p>First, the plugin object is fetched before it is replaced:</p> <ul> <li>line 416: $plugin = $key-&gt;getKeyInput(); -- still the previous input plugin</li> <li>line 428: $key-&gt;setPlugin('key_input', $key_input_id); -- the entity now points at the new one</li> <li>line 432 and line 461: $configuration is computed and then applied with $plugin-&gt;setConfiguration($configuration) -- onto the object the entity no longer uses</li> </ul> <p>Second, and this is the part that a reordering alone would not fix, the configuration being restored comes from the previous input plugin. For a key going from "text_field" to "generate" that configuration is an empty array, because text_field has no generated flag to carry. GenerateKeyInput therefore falls back to its defaultConfiguration(), which is generated: FALSE, and processSubmittedKeyValue() takes the branch that calls generateKeyValue().</p> <p>Worth stressing: the $use_original_key_value guard did fire in this test. The original key provider and the original key type are both unchanged, so the condition at line 449 is met. The guard is not being bypassed -- it simply does not consider that the key input plugin id itself may have changed underneath an unchanged key type.</p> <h4 id="summary-steps-reproduce">Steps to reproduce</h4> <ol> <li>Install a module providing a key type whose annotation declares key_value = { "plugin" = "text_field" }, and create a key of that type using the Configuration provider. Note the stored value.</li> <li>Change that key type's annotation to key_value = { "plugin" = "generate" } -- the code change a module would ship to start offering generated keys -- and rebuild the container.</li> <li>Open the existing key at /admin/config/system/keys/manage/KEY_ID. The Value section now reads "The key value will be automatically generated using the selected key type settings.", even though this key already has a value.</li> <li>Change only the key name. Touch nothing else.</li> <li>Save, then read the key value back, for example with drush php:eval on Key::load('KEY_ID')-&gt;getKeyValue().</li> </ol> <p>The value is different, and if the key type derives its length from its own settings, so is the length.</p> <h3 id="summary-proposed-resolution">Proposed resolution</h3> <p>updateKeyInput() should treat "the key input plugin changed while the key type did not" as a case where the existing key value must be preserved, rather than a case where a fresh input plugin starts from its defaults.</p> <p>Moving the $plugin assignment after setPlugin() is necessary but not sufficient on its own: the restored configuration would then land on the right object, but it still comes from the previous input plugin and still contains nothing that tells GenerateKeyInput a value already exists. Something has to carry that fact across -- for instance keeping $key_value_data['current'] populated and letting the new input plugin see it, or giving KeyInputBase a way to say "a value is already present, do not create one".</p> <p>Whichever shape is chosen, the outcome to aim for is that an existing key's value survives a key type's change of input plugin, and that generating a new value stays something an administrator asks for explicitly.</p> <h3 id="summary-remaining-tasks">Remaining tasks</h3> <ul> <li>Confirm the intended behaviour: should the existing value always be kept, or should the form warn and offer the choice? That is a maintainer call, and the fix depends on it.</li> <li>Patch, plus a kernel or functional test that saves an existing key after its key type has switched key_value.plugin and asserts the value is unchanged.</li> <li>I am happy to write both once the intended behaviour is settled, as a merge request if that is easier to review.</li> </ul> <h3 id="summary-ui-changes">User interface changes</h3> <p>None as reported. Depending on the resolution chosen, the Value section of the key edit form would stop offering to generate a value over a key that already has one.</p> <h3 id="summary-api-changes">API changes</h3> <p>None intended. If the fix needs key input plugins to be told that a value already exists, that would add to the KeyInput plugin contract, which is worth calling out before it is written.</p> <h3 id="summary-data-model-changes">Data model changes</h3> <p>None. The key entity already stores its key_input plugin id and settings, and those already change when the key type changes its declared input. What this issue is about is the key value stored by the provider being replaced as a side effect.</p> <h3 id="summary-related">Related</h3> <ul> <li><a href="https://www.drupal.org/i/2647106">#2647106</a> introduced the ability for key types to specify their key input plugin, which is the mechanism involved here.</li> <li><a href="https://www.drupal.org/i/3561668">#3561668</a> asks for the Encryption key type to generate its key automatically. That is the same change applied to a key type with existing keys in the wild, so this issue looks like a prerequisite for it.</li> <li>Not filed through the security process on purpose: this needs an administrator with permission to edit keys, acting on their own site's configuration, and it exposes nothing. It destroys availability of an existing key, which is why the priority is set to Major rather than Normal, but there is nothing here another party can trigger.</li> </ul>