Adds v1beta2 license support
#336
Open
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Updates kotskinds from v0.0.0-20230724164735-f83482cc9cfe to v0.0.0-20251023161058-b6489d3d51c5 to gain access to the new v1beta2 License API. This version includes both v1beta1 and v1beta2 license types, allowing the SDK to support both API versions during a gradual migration period. This is the first step toward supporting the new v1beta2 License API while maintaining backward compatibility with existing v1beta1 licenses. 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-Authored-By: Claude <[email protected]>
Introduces a new LicenseWrapper type that can hold either a v1beta1 or v1beta2 License object, providing a unified interface to access common license fields regardless of the API version. The wrapper includes: - Version detection methods (IsV1, IsV2) - Accessor methods for all common license fields (AppSlug, LicenseID, CustomerName, etc.) - Support for all boolean feature flags (IsAirgapSupported, IsGitOpsSupported, etc.) This abstraction allows the SDK to work with both license versions transparently, eliminating the need for version checks throughout the codebase. The wrapper always has exactly one field populated (either V1 or V2), never both. 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-Authored-By: Claude <[email protected]>
Modifies LoadLicenseFromBytes to detect and parse both v1beta1 and v1beta2 license formats, returning a LicenseWrapper that encapsulates the appropriate version. The loader now accepts both API versions and creates the correct wrapper type based on the detected GVK. Updates the Store interface and InMemoryStore implementation to use LicenseWrapper instead of the concrete v1beta1.License type. This enables the SDK to store and retrieve licenses of either version transparently. Key changes: - LoadLicenseFromBytes returns LicenseWrapper instead of *v1beta1.License - Store interface methods accept/return LicenseWrapper - InMemoryStore properly deep copies the correct license version - Uses wrapper accessor methods (GetAppSlug, GetLicenseType) instead of direct field access This completes the core infrastructure needed to support both license API versions throughout the SDK while maintaining a clean, version- agnostic API surface. 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-Authored-By: Claude <[email protected]>
Refactors signature verification to support both v1beta1 (MD5) and v1beta2 (SHA-256) licenses: - Refactors VerifySignature() to accept LicenseWrapper and dispatch to version-specific verification - Adds verifyV1Signature() for backward-compatible MD5 verification of v1beta1 licenses - Adds verifyV2Signature() for SHA-256 verification of v1beta2 licenses - Implements VerifySHA256() helper function using RSA-PSS with SHA-256 hashing This enables the SDK to verify v1beta2 licenses using the more secure SHA-256 algorithm instead of MD5, while maintaining full backward compatibility for existing v1beta1 licenses. [Phase 3 of v1beta2 license support] 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-Authored-By: Claude <[email protected]>
Updates all code to use the LicenseWrapper type instead of direct kotsv1beta1.License references. This completes the integration of the abstraction layer that supports both v1beta1 and v1beta2 license APIs. Changes include: - Update function signatures in pkg/license/, pkg/report/, pkg/handlers/, pkg/integration/, pkg/apiserver/, and pkg/upstream/ to accept LicenseWrapper - Replace direct license.Spec.* accesses with wrapper getter methods - Update imports to use licensetypes package - Modify LicenseInfo struct to support both v1 and v2 entitlements natively - Fix tests to construct and use LicenseWrapper pattern - Update mock store to work with LicenseWrapper This refactoring maintains backward compatibility with v1beta1 licenses while enabling future v1beta2 license support through the wrapper abstraction. 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-Authored-By: Claude <[email protected]>
Refactors pact test files to use the LicenseWrapper type instead of raw
kotsv1beta1.License pointers, ensuring the contract tests match the new
LicenseWrapper-based API signatures introduced in the license abstraction layer.
Changes include:
- Wrapping v1beta1.License instances in LicenseWrapper{V1: ...} in test setup
- Updating mock store expectations to return LicenseWrapper types
- Adding licensetypes import to all affected pact test files
This maintains pact contract compatibility while supporting both v1beta1 and
v1beta2 license APIs through the abstraction layer.
🤖 Generated with [Claude Code](https://claude.com/claude-code)
Co-Authored-By: Claude <[email protected]>
laverya
reviewed
Oct 24, 2025
laverya
reviewed
Oct 24, 2025
Changes: - Update InnerSignature struct to support dual-algorithm signatures (v1beta1 uses MD5, v1beta2 uses SHA-256) - Change v1beta2.License field from Signature256 to Signature - Update v1beta2 verification to use V2KeySignature and V2LicenseSignature - Add complete field-by-field validation for v1beta2 licenses - Add entitlement signature verification for both v1beta1 and v1beta2 - Add GetV2AppPublicKey helper function for v1beta2 entitlements - Update kotskinds to latest version from main The SDK now correctly unmarshals signatures from vandoor's dual-algorithm format where both MD5 and SHA-256 signatures are present in the same inner signature structure. 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-Authored-By: Claude <[email protected]>
Vandoor signs entitlement values using fmt.Sprint(), not JSON marshaling. Changed verification to use fmt.Sprint() to match vandoor's signing format. 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-Authored-By: Claude <[email protected]>
|
I would recommend updating this to use the latest kotskinds version, which includes builtin validation functions for each license version |
Updates github.com/replicatedhq/kotskinds from v0.0.0-20251024162531-2174a5b85a4d to v0.0.0-20251024204505-044aa5d007d5 to get the ValidateLicense() methods for both v1beta1 and v1beta2 licenses. 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-Authored-By: Claude <[email protected]>
Replaces custom crypto implementation with kotskinds' built-in ValidateLicense() method for both v1beta1 and v1beta2 licenses. This removes approximately 493 lines of custom RSA signature verification, license field validation, and entitlement signature checking code. The ValidateLicense() method handles: - MD5 signature verification for v1beta1 licenses - SHA-256 signature verification for v1beta2 licenses - License field integrity checks - Entitlement signature validation - Old and new signature format support 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-Authored-By: Claude <[email protected]>
Updates chart version and appVersion from 1.0.0 to 1.10.0 to reflect license validation improvements. 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-Authored-By: Claude <[email protected]>
I think this was a timing issue. The PR was created before I incorporated the |
The LicenseFieldSignature struct was only capturing v1 (MD5) signatures, causing v2 (SHA-256) signatures from v1beta2 licenses to be discarded during JSON unmarshaling. This resulted in empty signature objects when calling the /license/fields endpoint with v1beta2 licenses. Updated LicenseFieldSignature to include both v1 and v2 fields to support signature validation for both v1beta1 and v1beta2 license formats. 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-Authored-By: Claude <[email protected]>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
What does this PR do?
TL;DR
This update modernizes the SDK to handle multiple license versions, preparing for evolving license formats while maintaining backward compatibility.
Details
Introduces a new license wrapper pattern that enables seamless SDK operation with different license schema versions. Instead of being locked to a single
v1beta1license format, the code now uses a wrapper type that accommodates both existingv1beta1licenses and futurev1beta2licenses. This architectural change provides the flexibility needed for license schema evolution without breaking existing integrations.The implementation preserves all existing functionality through accessor methods on the wrapper, ensuring code that interacts with licenses continues working unchanged. The wrapper intelligently routes operations to the appropriate underlying license version—whether verifying signatures with MD5 for
v1beta1or SHA-256 forv1beta2, or accessing entitlements in their native format without conversion overhead.This positions the SDK to support an upcoming license enhancement while maintaining backward compatibility—a critical requirement for infrastructure tooling that must work reliably across diverse customer environments with varying license versions.
I feel weird about the next question…users can see this but it's also behind a feature flag so I think the answer is "NONE".
Does this PR introduce a user-facing change?