Provider name optionality

[ionut-arm]

Posted as a comment by Matt in #570.

[[provider]]
name="mbed-crypto-provider"

I know we originally made the provider name globally optional so that existing configs would not fail with new versions of Parsec. Would it be better for it to be optional for OnDisk KIM implementations (to ensure config stability), and required for SQLite KIM configs? This way it forces the user to edit the config and set the provider names with their "preferred" naming scheme; preventing the (probably common) case of a user changing from the OnDisk to SQLite KIM without reading any of the provider naming warnings (quoted below).

In my mind, by going from OnDisk -> SQLite the user is "opting-in" to a new feature-set and its requirements. The only concern from the stability requirements set out is New options should be optional. I would argue that, transitively, provider name in this case is optional as the manager_type="OnDisk" would have to be mutated to manager_type="SQLite" in order for provider name to become a required field.

Parsec Config Stability:

Old configuration files should still work with future stable Parsec versions, with the same default for optional options.

Configuration options should not disappear in future stable Parsec versions. Configuration defaults should remain the same. New options should be optional.

Current provider name warnings:

⚠ WARNING: Provider name cannot change.
⚠ WARNING: Choose a suitable naming scheme for your providers now.
⚠ WARNING: Provider name defaults to "mbed-crypto-provider" if not provided, you will not be able to change the provider's name from this if you decide to use the default.
⚠ WARNING: Changing provider name after use will lead to loss of existing keys.

On the note of these warnings. WARNING: Provider name cannot change. would probably read nicer as WARNING: Provider name should not change once set.. And maybe loss of existing keys to LOSS OF EXISTING KEYS to really drive the point home and draw the attention of skim readers.

Originally posted by @MattDavis00 in #570 (comment)

[ionut-arm]

Reply from @paulhowardarm:

Matt's point here makes me think that maybe our rules around config file stability need some refinement, because I would agree that there are cases where explicitly opting in to a new feature (and hence editing the config file anyway) might prompt the need for other required changes. The current rule of "new options should be optional" is perhaps rather too vague. The real intention here is simply to ensure that existing config files always continue working, but that's not the same as saying that it should be possible to edit one thing without changing anything else.

But then there is the question about what should be done in this specific case - should a switch to the SQL lite provider prompt the addition of names for existing providers? I'm in two minds about this. It might be enough simply to ensure that our out-of-box example config includes provider names. At the moment, a working deployment cannot be "switched" from on-disk to sql anyway, because there is no migration facility being offered as yet. If and when we decide to offer a migration path, we could possibly make it a requirement of that process to inject provider names into the config.

[ionut-arm]

a working deployment cannot be "switched" from on-disk to sql anyway

That's true, but it might be worth considering the "non-working-deployment" configs, like the default one in Fedora or openSUSE. Do we want those ones to be guided more stringently? Or is it better to collaborate with them on how the config file looks?

[paulhowardarm]

I would prefer to do this collaboratively - we need to be communicating the arrival of these new features so that distro maintainers can understand the impact on packaging - not just in terms of config tweaks, but also in terms of how to manage the new dependencies.

[ionut-arm]

Then I agree, doing this at the same time as #517 would make sense.

It might be enough simply to ensure that our out-of-box example config includes provider names.

That's covered!

[MattDavis00]

My logic behind bringing this up applies to existing installations, but was mainly focused on new installations. With my main concern being users not choosing their provider naming scheme.

I'm in two minds about what I think:

• With new deployments, administrators should explicitly have to set the provider name (themselves) with their preferred naming scheme. E.g. leaving the provider name field blank for them to fill in or something similar. Mainly because we currently have no way (currently) to migrate keys from one ProviderIdentity to a new ProviderIdentity, if they did wish to rename their providers at a later date.
• Give provider names pre-filled as it is an easier installation experience, which is nice. This would ensure that all of the example configs can be run "as is". Main downside is users may not change their provider names when configuring the service, leaving them trapped with the default provider name that they did not explicitly choose, which may not match their naming scheme.

Overall though, my opinion is:

That provider.name should not have an implicit default within the service, when using the SQLiteKeyInfoManager; it must be set in config.toml visible to the user for transparency.