-
Notifications
You must be signed in to change notification settings - Fork 33
feat: Add versioning support to plugins and scheme implementations (#120) #349
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: main
Are you sure you want to change the base?
Conversation
Implements issue veraison#120 - Versioning for plugins/scheme implementations Changes: - Add GetVersion() method to IPluggable interface - Update all RPC channels (evidence, endorsement, store) with version support - Add version tracking in PluginContext and loaders - Add GetPluginVersion() and GetSchemeVersion() to IManager interface - Implement version logging at INFO level during plugin discovery - Add scheme_versions to ServiceState proto for API exposure - Add SchemeVersion constant to all 6 attestation schemes (v1.0.0) - Implement GetVersion() in all scheme handlers (Evidence, Endorsement, Store) - Update test infrastructure and test plugins Scheme-level versioning approach: All handlers for a scheme share the same version, following the consensus from issue discussion. 43 files modified: 1 new documentation file, 42 modified files across plugin framework, RPC channels, proto definitions, and all scheme implementations (PSA_IOT, ARM_CCA, PARSEC_CCA, PARSEC_TPM, RIOT, TPM_ENACTTRUST). Closes veraison#120 Signed-off-by: Sukuna0007Abhi <[email protected]>
setrofim
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There appears to be some confusion as to what the version pertains. The documentation/API seems to imply that both plugins and schemes have versions, however the implementation implies the version is for the scheme.
This should be made clear in the API/docstrings.
(IMO, there is no need to version plugins separately, and version ought to be associated with the scheme).
|
|
||
| // GetPluginVersion returns the version string for a plugin identified | ||
| // by its name. If the plugin is not found, an error is returned. | ||
| GetPluginVersion(name string) (string, error) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is misleading. Per current inplementation, plugins do not independent version and this returns the version for the scheme, not the plugin. I would rename this to GetSchemeVersionForPlugin
| // by its name. If the plugin is not found, an error is returned. | ||
| GetPluginVersion(name string) (string, error) | ||
|
|
||
| // GetSchemeVersion returns the version string for the plugin that |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This returns the version for the scheme, not for a plugin (a scheme has three plugins associated with it, but, currently, they do not have independent versions).
| const SchemeName = "ARM_CCA" | ||
| const ( | ||
| SchemeName = "ARM_CCA" | ||
| SchemeVersion = "1.0.0" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Please change all versions to 0.0.1. (Version 1.0.0 implies that the implementation is final, and currently none of them are).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sure sir @setrofim
Plugin Versioning Implementation
Implements Issue #120 - Versioning for plugins/scheme implementations
Summary
This PR adds comprehensive versioning support to Veraison's plugin system, enabling clients to query and understand the level of support and capabilities associated with specific plugin implementations.
Requirements Addressed
Implementation Approach
Scheme-level versioning: All pluggables associated with a scheme (evidence handler, endorsement handler, store handler) share the same version, consistent with how they share the scheme name.
Key Changes
Core Plugin Interface
Added GetVersion() string method to IPluggable interface. All plugins must now return a semantic version string (e.g., "1.0.0").
Version Query API
Manager Interface (plugin/imanager.go):
ServiceState API (proto/state.proto):
Version Logging
Plugin versions are logged at INFO level during discovery:
loaded plugin | name=psa-evidence-handler scheme=PSA_IOT version=1.0.0 path=...
Scheme Versions
All attestation schemes updated to version 1.0.0:
PSA_IOT, ARM_CCA, PARSEC_CCA, PARSEC_TPM, RIOT, TPM_ENACTTRUST
Files Modified
43 files total:
Usage Examples
Programmatic Query:
version, err := pluginManager.GetPluginVersion("psa-evidence-handler")
version, err := pluginManager.GetSchemeVersion("PSA_IOT")
REST API Query:
GET /verification/v1/state
Response includes scheme_versions map with all scheme versions.
Testing
All packages compile successfully with no errors or warnings. Test infrastructure has been updated to support versioning.
Breaking Changes
This is a breaking change for existing plugin implementations. All plugins must now implement the GetVersion() string method. External plugins will need to be updated accordingly.
Documentation
Added PLUGIN_VERSIONING.md with detailed implementation notes and usage examples.
Closes #120
Regards - Abhijit Das...