Sign CLI: signature provider plugins

[dtivel]

Markdown

Currently, Sign CLI only supports signing with Azure Key Vault. Sign CLI should support pluggable signature providers to enable other private key storage options. This is necessary to keep pace with recent CAB Forum changes to private key storage requirements for publicly trusted code signing certificates.

CC @clairernovotny, @richlander

[richlander]

Looks good.

I'm seeing a lot over similarity / overlap with .NET tools. It would be good to talk with the tools folks to see if there can be sharing here. For example, tools are a specific package type.

On roll-forward, LatestMajor is probably the wrong setting. Context here: https://github.com/dotnet/sdk/pull/37231

It seems like this project is 90%+ of the way to defining a generic plug-in model system for .NET. That's really interesting. We should talk to the app model folks about that.

@vitek-karas @baronfel

[agocke]

Sorry, I haven't had time to read the full proposal, but I see that it relies on an assembly load from disk as an extensibility point. This security model would devolve to arbitrary code execution, mediated by the security of the file system and the file loading code.

That seems like a very large security surface area. I'm not ruling out that assembly load may be necessary for this level of extensibility, but does pose a substantial risk. I think we should at minimum do a full security review of the plugin loading design. Alternatively, if we can build an extensibility model that doesn't require assembly load, that might be easier to secure.

[baronfel]

I had a chat with @clairernovotny a bit ago and we covered a few points of interest to this design. There are a few major points that we covered around

• Discoverability (both end-user knowledge of what plugins are available to be installed, and tool-plugin knowledge of what plugs are currently installed)
• UX of the CLI interface to the resulting sign command: dotnet sign providerA may have drastically different arguments than dotnet sign providerB, and so each provider needs to be able to communicate its own set of arguments to the 'core' sign tool for areas like Help, Tab Completions, etc.
• Hosting/Invocation of each loaded plugin - aka the protocol that each plugin would need to adhere to to actually sign things

To me the areas in which this tool differs from the extensibility model of systems like Git credential helpers or Docker credential helpers are these latter two areas. These credential-helper extensibility models have a very limited and defined protocol, with little in the way of CLI-based customization. They are also fairly stateless - each invocation is distinct. The proposed model for plugins implies more persistence - based on my conversation with @clairernovotny each plugin is called repeatedly in a single signing session in a way that would require a whole rework of the protocol to support with an out-of-proc model in order to not tank performance. That could be done (@dtivel has signaled above that such designs might be useful) but it would definitely cause more delay here.

One potential comparison point here would be the git CLI itself - it has convention-based lookups for commands of the form git-MY_COMMAND_HERE, but it does so at the cost of potentially losing consistency of help/tab completions/etc - is that a cost we'd be willing to pay for that tool?

I think these differences are unique enough to not stop work here while we figure out some unified plugin plan.

[anangaur]

@dtivel @baronfel @clairernovotny please take a look at prior art here: https://youtu.be/FRrslz_AHzE?list=PLdo4fOcmZ0oWiK8r9OkJM3MUUL7_bOT9z&t=460 This is Microsoft owned dotnet tool Upgrade Assistant

[jkotas]

@dtivel @baronfel @clairernovotny please take a look at prior art here: https://youtu.be/FRrslz_AHzE?list=PLdo4fOcmZ0oWiK8r9OkJM3MUUL7_bOT9z&t=460 This is Microsoft owned dotnet tool Upgrade Assistant

I do not see the extensions feature in the current release of the upgrade-assistant tool. Was it removed? (It would not surprise me given the versioning issues - like the ones discussed here - that comes with it.)

C:\>dotnet tool install -g upgrade-assistant
Skipping NuGet package signature verification.

C:\>upgrade-assistant extensions --help

Error: Unknown command 'extensions'.

       extensions --help
       ^^^^^^^^^^ No such command


C:\>upgrade-assistant --help
USAGE:
    upgrade-assistant [OPTIONS] <COMMAND>

EXAMPLES:
    upgrade-assistant upgrade <PROJECT_PATH>
    upgrade-assistant upgrade <PROJECT_PATH> --operation Inplace --targetFramework net6.0
    upgrade-assistant upgrade <PROJECT_PATH> --operation SideBySide --targetFramework LTS --destination
<NEW_PROJECT_NAME_OR_PATH>

OPTIONS:
    -h, --help       Prints help information
    -v, --version    Prints version information

COMMANDS:
    upgrade    Upgrade project or its features. This command lets you pick upgrade options and guides through upgrade
               process