Uh oh!
There was an error while loading. Please reload this page.
docs: describe the security boundary and how to harden a plugin - #24
Merged
Conversation
The SDK ships no anti-tamper, anti-debug, obfuscation or integrity-checking code, and that is a deliberate scope decision rather than an oversight. Nothing in the documentation said so, so a reader could reasonably finish the README believing it was a DRM layer, wire `licensedFlag()` into a single `processBlock` branch, and ship. A new "Security and hardening" section sits between the device fingerprint and 3.x migration sections, keeping the trust material together: how the binding is computed, then what it does and does not buy you. It states what the SDK guarantees (only Moonbase can mint a token, the product and device bindings, the bounded grace period, the store being a cache rather than a credential, fail-closed defaults), why hardening is deliberately left to the consumer, and seven principles for doing it. The rationale for the boundary is the part worth keeping: hardening only works when it lives inside your binary and is specific to it, so anything general enough to ship in an open-source header would be public, identical in every plugin using it, and one published bypass would apply to all of them. Guidance is positive throughout. The section does not enumerate the SDK's weak points or publish attack recipes. Much of the reasoning already existed in code comments that consumers never read, notably the on-disk cache warning in device_id_resolver.hpp and the fail-closed default in LicenseGate.h.
The latest updates on your projects. Learn more about Argos notifications ↗︎
|
Uh oh!
There was an error while loading. Please reload this page.
🎉 This PR is included in version 4.2.0 🎉 The release is available on GitHub release Your semantic-release bot 📦🚀 |
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
Sign up for freeto join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
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.
Adds a "Security and hardening" section to the README, sitting between the device fingerprint and 3.x migration sections so the trust material reads as one run: how the binding is computed, then what it does and does not buy you. It states what the SDK guarantees (only Moonbase can mint a token, the product and device bindings, the bounded grace period, the store being a cache rather than a credential, fail-closed defaults), why anti-tamper and obfuscation are deliberately left to the consumer, and seven principles for doing that well. The rationale for the boundary is the part worth keeping: hardening only works when it lives inside your binary and is specific to it, so anything general enough to ship in an open-source header would be public, identical in every plugin using it, and one published bypass would apply to all of them. Guidance is positive throughout, with no enumeration of the SDK's weak points and no attack recipes, and much of the reasoning already existed in code comments consumers never read (the on-disk cache warning in
device_id_resolver.hpp, the fail-closed default inLicenseGate.h).Docs only, no code changes.