Secure Download and Provenance: The Baseline Design for Source Code Sales

This product update addresses an old but often overlooked question: the baseline of source code delivery is not only that it can be sent, but that it can be sent under control.

From delivering files to delivering permissions

The risk of source code sales is that a single copy may remain outside control for a long time. We therefore shift the delivery object from a downloadable archive to a set of verifiable, expirable, and revocable download permissions. Files remain in object storage, but buyers do not receive a permanent address; they receive a short-lived signed link generated after a request.

Short-lived signatures: links exist only as long as necessary

When a download request arrives, the server verifies the order, license status, remaining count, and file fingerprint, then issues an access signature with an expiration time. The signature is bound to the order and file checksum, and becomes invalid on expiry; when necessary, it can be limited to a single use. Signing keys are hosted by a key management service and rotated regularly. The application requests only minimum permissions and does not expose plaintext keys in databases, logs, or the frontend.

Download counts and the license pool: turning commercial promises into computable constraints

Download counts constrain retrieval behavior without changing the granted right of use; the license pool manages authorization capacity and status. Each sale allocates a license from the pool, and download counts and licenses are recorded independently, avoiding the mistake of treating how many times a file can be downloaded as how long it is licensed. When a refund, breach, or risk-control event occurs, freezing the corresponding entry in the license pool stops further delivery. The key point is that buyers do not hold plaintext download keys; they hold only short-term credentials bound to their orders. The server also does not store download keys that can be directly reused.

Fingerprint files: making every delivery traceable

Each time a delivery package is generated, a fingerprint file is attached, recording the order identifier, license identifier, file checksum, generation time, and signature. It does not alter source code semantics, but it allows copies in later circulation to be traced back to a specific delivery batch. The fingerprint file should be signed together with the package manifest and checksum to prevent separate replacement. The purpose of provenance is not deterrence, but providing verifiable evidence in authorization disputes, leak investigations, and compliance audits.

Audit, revocation, and minimal exposure

Download events record the order, license, fingerprint, result, and necessary request context; sensitive fields are redacted, and logs do not record plaintext keys. Revocation is achieved through expiring signatures, freezing licenses, and marking fingerprints. Historical records are retained, but authorization does not continue. Engineering-wise, we hold three baselines: do not persist plaintext download keys by default; separate signing permissions from download permissions; and leave audit traces for any manual operation.

Baseline checklist

• Download links use short-lived signatures and are not stored by default
• Download counts and the license pool constrain separately
• Every delivery carries a signed fingerprint file and checksum
• Buyers do not hold plaintext download keys
• Keys are hosted, rotated, and least-privileged
• Downloads, revocations, and anomalies are auditable