Move the plugin installation properties from sign to setup action
FeynmanZhou opened this issue · comments
The sign action requires users to input notation plugin installation properties. As a user, I would expect the plugin installation can be configured and completed in the setup action.
It would be much efficient and flexible if users sign a image multiple times using a Notation Sign action, without specifying the plugin installation each time.
In addition, if users have multiple plugins, they just need to specify which plugin to use in signing, without installing the plugin per running sign action.
Is it possible to move the plugin installation properties from sign action to setup action as follows?
Notation Setup
- name: setup Notation CLI
uses: notaryproject/notation-action/setup@v1
with:
version: <version_of_official_Notation_CLI_release>
url: <url_of_customized_Notation_CLI>
checksum: <SHA256_of_the_customized_Notation_CLI>
plugin_name: <notation_signing_plugin_name>
plugin_url: <plugin_download_url>
plugin_checksum: <SHA256_of_the_signing_plugin>
Notation Sign
- name: sign releasd artifact with signing plugin
uses: notaryproject/notation-action/sign@v1
with:
plugin: <which_plugin_to_use>
key_id: <key_identifier_to_sign>
target_artifact_reference: <target_artifact_reference_in_remote_registry>
signature_format: <signature_envelope_format>
plugin_config: <list_of_plugin_defined_configs>
allow_referrers_api: <boolean_flag_for_referrers_api>
An open discussion with my thoughts:
The current design is extensible. Because the verify action is not supporting verification through a plugin at the moment. If one day we want to support it, then a user can setup a Notation CLI, use plugin 1 for sign and use plugin 2 for verify. (given plugin 1 only has signing capability and plugin 2 only has verification capability).
(@FeynmanZhou, JFYI, the current design does check if plugin already exists. If yes, it won't install it again. so we are not installing the plugin per running.)
The proposed design moves plugin installation to setup, which is not as flexible as the current design? Because, now the user needs to provide both plugin 1 and plugin 2 to setup action. In addition, they also need to tell Notation GHA which plugin should be used for sign and verify accordingly.
@FeynmanZhou @shizhMSFT Any thoughts/comments/suggestions on this one?
The current design is flexible and if/when verify plugins are supported, it would indeed be complicated to move all plugin config on setup and configure multiple at that time.
However, the current setup is inviting human error. For instance, if an image, SBOM and vulnerability scan result are all being signed in a single job, I have to include all required plugin information 3 times. When I go to upgrade the plugin version, I'll have multiple places to update the URL and checksum. Missing one property could result in an error, e.g. a conflict between version and checksum. What happens if a job refers to 2 versions of the same plugin with the same name -- is the determination that the plugin exists checking by name or by name & version?
Maybe the solution is to have a "setup-plugin" action? This could be done once per plugin in the job/workflow, regardless of how often said plugin is used. Yes, the name will still have to be provided with every sign and verify, but this will ensure the same version of the plugin is used and reduces the chance of user-introduced errors or confusion.