Build compilé
Compilez votre application en binaire natif avec la barrière de licence insérée automatiquement dans chaque module — aucun Python en clair n'est livré, et 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 insère automatiquement une vérification de la barrière de licence dans chaque module de votre arborescence source, tisse cette barrière directement dans le code natif compilé, chiffre les modèles que vous embarquez, intègre la clé publique de votre éditeur, et compile le tout — si bien qu'il n'y a aucun Python en clair à lire, ni 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. magiclock build app.py parcourt chaque module .py accessible depuis app.py 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.air.bootstrap(), vous n'avez donc pas à en ajouter un vous-même :
# your source, unchanged — no decorator, no bootstrap() call added by hand
def export_report(data: str) -> bytes:
return render_pdf(data)magiclock build app.py # every module in the tree — including this one — is gated automaticallyUne 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
magiclock build app.py # -> dist/app.<...>.so (single compiled module)
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)| Option | Défaut | Signification |
|---|---|---|
-o, --output-dir | dist | Où la sortie du build est écrite. |
--source-root | le fichier d'entrée | Racine 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-compile | dé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-tmp | désactivé | Conserver le répertoire de transformation intermédiaire au lieu de le nettoyer. |
--model PATH | aucun | Chiffrer un modèle et l'embarquer dans le build. Répétable. |
--model-lock-passphrase | désactivé | Ajouter une phrase secrète comme second facteur sur les modèles embarqués (nécessite au moins un --model). |
--model-trial / --model-expires-in / --model-expires-at | aucun | Expiration des modèles embarqués — mêmes sémantiques que les options d'expiration de Chiffrer le code, mutuellement exclusives entre elles. |
--no-bind-machine | désactivé | Build portable pour des machines que vous ne contrôlez pas : aucune barrière de licence n'est compilée (le binaire s'exécute partout, sans activation), et les modèles embarqués sont chiffrés avec une clé partagée au lieu de cette machine. Avec --emit-key, une clé aléatoire est générée et affichée ; avec --passphrase, la clé est dérivée d'une phrase secrète. |
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 binaire compilé est lié à 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 sur une seconde station de travail ou un serveur de déploiement, activez aussi cette machine sous votre compte et compilez dessus.
Pour distribuer une application compilée vers les machines d'utilisateurs finaux — des machines que vous ne contrôlez pas et qui ne seront jamais activées — compilez avec --no-bind-machine. Le binaire s'exécute alors partout, sans compte ni coffre, et ses modèles embarqués se déchiffrent avec la clé que vous distribuez (magiclock.open_model(path, key=...) ou passphrase=...). Un build portable n'a pas de barrière de licence : la protection repose sur la compilation native elle-même plus le secret — et, avec --web-gate, sur un interrupteur d'arrêt à distance que vous conservez après livraison (voir Contrôle cloud).
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.