SECURITY · STORE · Updated 2026-09-10 · Createrun Engineering

Createrun Store dual-signature explained

A publisher signature and a Store signature represent different authorities. The first links a release to its publisher; the second records Store approval of the signed release.

What a signature establishes

A digital signature can detect unauthorized changes and authenticate a signatory. A single signature can already provide integrity protection when the verifier uses the trusted key and checks the artifact it actually received. This is the purpose described by NIST's Digital Signature Standard.

Accepting an attacker's replacement key or reusing a verification result for different bytes breaks that trust model. Adding a second signature does not by itself fix an incorrectly implemented verifier.

Why use two authorities?

Createrun's package design separates publisher authorization from Store approval. A publisher prepares a versioned application package and signs it. The Createrun Store adds its approval signature through the distribution process. Installation checks the required signatures and the package's integrity.

This separation lets an installer require both approvals for a release. It does not mean that two signatures are a source-code security audit or that any signed application is safe to run.

The threat model

• A mirror or network intermediary can replace downloaded bytes. Verification against trusted keys must reject altered signed content.
• A stolen publisher key can authorize a malicious submission. Independent review adds another control, but reviewers are not guaranteed to detect the compromise or every harmful behavior.
• Compromise of a signing service requires key revocation and incident response. The effectiveness of recovery depends on which verifiers receive and apply the updated trust information.
• An old, correctly signed release may still be unsuitable. Version selection and update policy are separate from proving the signature is valid.

What signatures do not establish

A signed package can contain a defect, unsafe integration or intentionally malicious logic. Review scope, runtime permissions and application testing remain relevant. Ask what checks a release actually passed; do not infer a line-by-line review or behavioral sandbox result from the approval signature alone.

Third-party assets loaded later by an application introduce their own integrity boundary. Requiring integrity hashes for those assets is a roadmap item, not a property every existing package can be assumed to have.

Operating the update path

Connected instances can discover signed updates; the customer controls when an application update is applied. Staging and best-effort recovery do not guarantee restoration of every database change or external API effect. Test backups and recovery with the application's actual dependencies.

An instance-bound license is another check in the install and activation path. Its validity is separate from package integrity and does not prove that a published version is appropriate for your workload.

What to request in a review

Ask for the package format and verifier behavior for your version, the trusted-key configuration, the review scope and the key-revocation procedure. Include disconnected instances in that review if your deployment uses them.

The security overview covers platform controls. The Createrun Store page explains publisher access and service status.

Back to blog