Signature de code ad hoc
Pour les applications tierces et les fichiers binaires que vous compilez vous-même et qui nécessitent la signature de code, utilisez une signature de code ad hoc .
- Je suppose que l'application ne fonctionnera pas sans signature;
- Je suppose que la demande ne sera pas distribuée;
- Je suppose que vous ne vous souciez pas que l'identité de la signature soit valide.
Une signature ad hoc n'offre pas d'avantages de sécurité fiables. Il peut être utilisé pour déterminer si l'application a été modifiée et il peut être utilisé pour appliquer des restrictions de sécurité, telles que des droits, à une application.
Une signature ad hoc validera codesignmais pas spctl. Cela peut ou non être important selon le binaire signé. Pour les applications et les exécutables, il est peu probable que cela ait de l'importance car il spctln'est pas exécuté sur des fichiers binaires créés localement.
Pourquoi Code Sign?
Concernant la question raffinée:
Comment dois-je gérer le code source non signé que je compile moi-même, car je ne m'attends pas à ce que les contributeurs puissent toujours signer ou se souvenir de leur code, surtout lorsqu'il s'agit de petites contributions à des projets open source avec de nombreux contributeurs.
Pour la plupart des applications auto-compilées, la signature de code n'est pas nécessaire. Cela suppose que vous faites confiance au code de l'application. Sur macOS, vous pouvez ouvrir des applications non fiables à partir du Finder, voir Ouvrir une application d' Apple à partir d'un développeur non identifié .
Si vous ne faites pas confiance au code ou aux développeurs, ne compilez pas ou n'exécutez pas l'application.
Votre responsabilité
Le fournisseur du code source n'a aucune responsabilité ni obligation de fournir des binaires signés pré-construits. Étant auto-compilé, toute signature de code est votre choix et votre responsabilité.
Apple exige que les soumissions à leurs App Stores soient signées par code.
Apple demande aux développeurs en dehors de leurs App Stores de signer leur code, mais il n'est pas encore requis.
Dans les deux cas, seuls les binaires finaux sont signés. Le code source et les ressources d'origine ne sont pas signés.
Le code source n'est pas signé
Le code source lui-même ne peut pas être signé de manière significative pour macOS. Les fichiers source et le code peuvent être signés numériquement, comme tout autre fichier, mais cela n'a aucun impact sur la façon dont l'application ou le binaire résultant est traité par macOS.
Comment faire pour signer un code ad hoc sur une application Mac
Pour coder une application sur macOS avec une signature ad hoc, définissez l' -sindicateur d' identité sur -:
codesign --force -s - </path/to/application>
Toutes les autres règles, exigences et permutations de la codesigncommande restent les mêmes.
Le drapeau --forceest utilisé ici pour remplacer toute signature existante.
Vous devrez peut-être ajouter l' --deepindicateur à la codesigncommande pour signer les sous-ressources telles que les infrastructures et les services intégrés.
Signer le programme vous-même ne ruine pas l'objectif de la signature de code. L'objectif général de la signature de code est de permettre de vérifier que le programme est une copie non modifiée créée à l'origine par une entité spécifique (personne ou entreprise). Lorsque vous signez un programme vous-même uniquement pour l'exécuter sur votre ordinateur, vous permettez au système de vérifier que c'est bien vous qui avez créé le binaire, et qu'il n'a pas été modifié par d'autres.
La différence qualitative entre signer vous-même l'application binaire et autoriser simplement les applications de développeurs non identifiés dans GateKeeper est que dans le premier cas, vous autorisez une seule application spécifique à s'exécuter - tandis que dans le second, vous ouvrez la possibilité que vous puissiez ouvrir un grand nombre de différentes applications simplement en cliquant dessus avec le bouton droit et en choisissant Ouvrir. C'est-à-dire qu'il est plus restrictif et donc un peu plus «sécurisé» en signant vous-même le programme spécifique.
La responsabilité de la signature vous appartient entièrement. Le développeur open source ne peut pas signer le code source - il est seulement possible de signer les binaires compilés. Lorsque vous produisez vous-même les fichiers binaires compilés, il vous incombe de les signer.
Vous pouvez créer un compte développeur sur le site Web d'Apple qui vous permettra de créer un certificat pouvant être utilisé pour la signature. Si vous êtes développeur et compilez régulièrement des fichiers binaires pour les exécuter sur Mac, c'est la façon préférée de faire les choses. Si c'est une chose unique que vous ne ferez probablement plus jamais, il est probablement exagéré de passer par ce processus. YMMV.
D'autres réponses à votre question ici vous recommandent d'utiliser une signature ad hoc pour votre binaire. Ça ne marchera pas. Vous devrez générer une signature valide pour que le binaire s'exécute avec GateKeeper sur son paramètre le plus sécurisé.
la source
Si vous n'êtes pas développeur, alors non.
La signature de code, en bref, est une méthode pour dire que vous (le développeur) êtes qui vous dites et que le code n'a pas changé depuis votre dernière signature.
Cela ressemble à votre signature de code déroutante (ce qui est requis par les développeurs pour publier des applications sur l'App Store) et Gatekeeper (ce qui protège votre Mac contre l'installation de logiciels de développeurs non identifiés).
Si vous autorisez votre Mac à installer des logiciels à la fois sur l'App Store et les développeurs identifiés, vous obtiendrez toujours la fenêtre contextuelle vous avertissant que le logiciel sera installé
Et s'il s'agit d'un développeur non identifié, vous obtiendrez le même popup avec une "icône d'avertissement"
Vous pouvez toujours installer le logiciel. Il s'agit simplement d'un mécanisme qui force l'interaction de l'utilisateur à installer réellement le logiciel, vous offrant une couche de sécurité contre les logiciels malveillants auto-installés.
la source