Build compilé

Compilez votre application en binaire natif — aucun Python en clair n'est livré. Portable par défaut ; avec --bind-machine, la barrière de licence est insérée automatiquement dans chaque module, si bien qu'il n'y a pas de vérification unique à trouver et supprimer.

Le niveau pratique livre du bytecode Python lisible une fois déchiffré. magiclock build va plus loin : il compile toute votre arborescence source en code machine natif et chiffre les modèles que vous embarquez — si bien qu'aucun Python en clair n'est livré, du tout. Par défaut, le résultat est portable : il s'exécute sur n'importe quelle machine, sans compte et sans activation. Compilez avec --bind-machine et il insère en plus une vérification de la barrière de licence dans chaque module, tisse cette barrière directement dans le code natif compilé et intègre la clé publique de votre éditeur — si bien qu'il n'y a aucune vérification unique qu'un attaquant pourrait trouver et neutraliser.

Rien à annoter

Il n'y a pas de décorateur et rien à annoter — vous ne modifiez pas du tout votre source. Sur un build --bind-machine (ou --web-gate), magiclock build parcourt chaque module .py accessible depuis votre point d'entrée et insère une vérification de barrière par module (contrôlant la capacité python_protect) avant la compilation. Le module d'entrée reçoit aussi automatiquement un appel magiclock.bootstrap(), vous n'avez donc pas à en ajouter un vous-même :

python
# your source, unchanged — no decorator, no bootstrap() call added by hand
def export_report(data: str) -> bytes:
    return render_pdf(data)
shell
magiclock build app.py --bind-machine   # every module in the tree — including this one — is gated automatically

Une vérification de barrière s'exécute une fois par module, la première fois que Python l'importe dans un processus — c'est un point de contrôle par module, pas par appel de fonction (voir Modèle de sécurité pour ce que cela implique pour les processus de longue durée et l'expiration/la révocation).

Compiler

shell
magiclock build app.py                        # -> dist/app.<...>.so   (portable by default — runs anywhere)
magiclock build app.py --bind-machine          # machine-locked build with the per-module license gate
magiclock build app.py --standalone            # a self-contained app directory instead
magiclock build app.py --no-compile            # scan + inject + embed only — skip compiling (no C toolchain needed)
magiclock build app.py --model weights.onnx    # also encrypt a model into the build (repeatable)
OptionDéfautSignification
-o, --output-dirdistOù la sortie du build est écrite.
--source-rootle fichier d'entréeRacine du projet à analyser/transformer (utilisez-la si app.py n'est pas au niveau supérieur de votre projet).
--module—Compiler en extension native monofichier (la cible par défaut).
--standalone—Compiler en répertoire d'application autonome plutôt qu'en module unique. Mutuellement exclusif avec --module.
--no-compiledésactivéAnalyser, injecter la barrière et intégrer les ressources, mais sauter la compilation native — utile pour inspecter la transformation, ou sur une machine sans chaîne d'outils C.
--keep-tmpdésactivéConserver le répertoire de transformation intermédiaire au lieu de le nettoyer.
--model PATHaucunChiffrer un modèle et l'embarquer dans le build. Répétable.
--model-lock-passphrasedésactivéAjouter une phrase secrète comme second facteur sur les modèles embarqués (nécessite au moins un --model et --bind-machine).
--model-trial / --model-expires-in / --model-expires-ataucunExpiration des modèles embarqués — mêmes sémantiques que les options d'expiration de Chiffrer le code, mutuellement exclusives entre elles.
--bind-machinedésactivéBuild verrouillé machine : une barrière de licence est compilée dans le binaire, qui ne s'exécute que sous le coffre activé de cette machine ; les modèles embarqués sont chiffrés vers la clé de cette machine. Sans elle, le build est portable (le défaut — voir ci-dessous).
--passphrase / --emit-keydésactivéPour les builds portables, place un secret sur les modèles embarqués au lieu du défaut sans clé : --passphrase dérive la clé des modèles d'une phrase secrète ; --emit-key génère et affiche une clé aléatoire.

Ce qui est livré

Le .so/.pyd/répertoire autonome compilé ne nécessite ni installation de MagicLock, ni compte, ni réseau sur la machine qui l'exécute — le déchiffrement et la vérification de licence sont tous deux entièrement hors ligne (voir Modèle de sécurité).

Par défaut, le build est portable : le binaire s'exécute partout, sans compte ni coffre, aucune barrière de licence n'est compilée, et les modèles embarqués sont sans clé par défaut — ils se déchiffrent d'eux-mêmes, via le runtime compilé, sur n'importe quelle machine. La protection repose alors sur la compilation native elle-même (plus, si vous en choisissez un, le secret des modèles : --emit-key affiche une clé à distribuer, --passphrase en dérive une, et le binaire les lit via magiclock.open_model(path, key=...) ou passphrase=...). Ajoutez --web-gate pour conserver un interrupteur d'arrêt à distance après livraison (voir Contrôle cloud) — un build portable reste librement distribuable et stoppable à distance.

Compilez avec --bind-machine pour au contraire verrouiller le binaire sur la machine qui l'a compilé : le build grave dans le binaire une déclaration signée désignant le siège de cette machine, et la barrière d'exécution refuse de tourner sous le coffre de toute autre machine — même activée. Les modèles embarqués sont en outre chiffrés vers la clé de cette machine. Si vous avez besoin du même programme verrouillé machine sur une seconde station de travail ou un serveur de déploiement, activez aussi cette machine sous votre compte et compilez dessus.

La suite

  • Modèle de sécurité — pourquoi le niveau compilé résiste au contournement « trouver et neutraliser la vérification » que le niveau pratique ne peut pas totalement exclure.
  • Compte et activation — activer des machines supplémentaires de build/déploiement.