Comment se débarrasser du pare-feu «Accepter les connexions entrantes»?

J'ai si souvent accepté que le pare-feu devait déjà s'en souvenir.

Par exemple, je l’obtiens pour Eclipse lors du démarrage de mes programmes java en mode débogage ... parfois, cette boîte de dialogue ne s’affiche que très brièvement (demi-seconde, par exemple) et disparaît. Je le récupère également pour iTunes (lorsque j'active le partage de ma bibliothèque) et pour d'autres programmes, même si je les ai répertoriés dans le panneau des préférences du pare-feu (paramètres avancés).

Il y a deux options ici:

1. Vous pouvez simplement sélectionner "Autoriser tout" dans votre pare-feu ou simplement le désactiver.
2. Vous pouvez supprimer les applications de la liste, supprimer le plistfichier correspondant à ces applications, les exécuter, puis les ajouter à la liste. Le plist est responsable de nombreux comportements et je suis prêt à parier qu'une mise à niveau du système d'exploitation ou de l'application peut entraîner la rupture du "lien".

À propos des plistfichiers ... Un plist est un type spécial de fichier texte contenant les propriétés de l'application et d'autres ressources, généralement le système d'exploitation, utilisées pour conserver et réutiliser les informations nécessaires à l'exécution de l'application. plistest un type de fichier et a de nombreuses utilisations, stockant généralement les préférences de l'utilisateur, mais il s'agit essentiellement d'un fichier XML. Vous pouvez vérifier s'il existe des caches, généralement des plistfichiers, pour les applications en question dans /Library/Cacheset /System/Library/Caches. Il y en a aussi un, ~/Library/Caches/mais de mauvaises choses peuvent se produire lorsque vous vous y perdez, alors laissez-le tranquille. Le système va dans ces dossiers pour une grande variété de raisons, et je nettoie généralement les deux premiers dossiers que je cite complètement environ une fois par mois.

sudo codesign --force --deep --sign - /path/to/application.app

Je n'ai jamais eu à créer de certificat en utilisant cette méthode.

Si cela ne vous aide pas, essayez sans --deepet sans la barre oblique suivante:

sudo codesign --force --sign - /path/to/application.app

Remarque, pour que ce soit plus clair: après avoir appliqué la signature, démarrez l'application, acceptez une dernière fois les connexions entrantes, puis quittez et redémarrez pour vérifier que la requête est partie.

Bien que le lien de RedYeti soit utile, il suffit de sauvegarder quelques clics pour que les autres me permettent de récapituler comment générer un certificat de signature de code et l'utiliser pour la (nouvelle) signature de code:

1. Créez votre propre certificat de signature de code:

   • Dans Accès au trousseau, Accès au trousseau> Assistant de certificat> Créer un certificat. Ceci lance l'assistant de certification:

   • Nom: Entrez ici une chaîne arbitraire dont vous vous souviendrez. Évitez les espaces, sinon vous devrez échapper le nom du certificat lorsque vous utilisez codesignla ligne de commande.

   • Type d'identité: Racine auto-signée

   • Type de certificat: Code Signing

   • Cochez la case "Permettez-moi de remplacer les valeurs par défaut", c'est assez important

   • Numéro de série: 1 (OK tant que la combinaison nom / numéro de série du certificat est unique)

   • Période de validité: 3650 (vous donne 10 ans)

   • Email, Nom, etc. remplissez comme vous voulez.

   • Info paire de clés: défini sur RSA, 2048 bits. N'importe pas vraiment à mon humble avis.

   • De "Key usage extension" à "Subject Alternate Name Extension": acceptez les valeurs par défaut.

   • Emplacement: trousseau de connexion.

   • Une fois celui-ci créé, définissez-le sur "Toujours faire confiance" dans le trousseau de connexion: faites un clic droit sur le certificat, choisissez "Lire les informations", puis dans la section "Confiance", définissez "Lors de l'utilisation de ce certificat" sur "Toujours faire confiance".

2. Re-signer une application: codesign -f --deep -s <certname> /path/to/app

3. Vérifiez que cela a fonctionné: codesign -dvvvv /path/to/app

Prendre plaisir!

MISE À JOUR: Les gens me demandaient pourquoi cela "ne fonctionnait pas" dans macOS 10.14 "Mojave". Maintenant que j'ai enfin mis à jour :-), voici ce que j'ai appris.

Fondamentalement, n'utilisez pas de certificat auto-signé pour la signature de code. Générez un certificat à l'aide de votre identifiant Apple dans Xcode . Pour récapituler brièvement les étapes:

Dans Xcode> Préférences> Comptes, sélectionnez votre identifiant de développeur Apple, cliquez sur "Gérer les certificats", sélectionnez le "+" dans le coin inférieur gauche, l'option "Développement Apple" vous est proposée. Sélectionnez cela, cela fera un certificat pour vous. En appuyant sur Ctrl-clic sur le nouveau certificat, vous pouvez l'exporter (au .p12format), puis en openchargeant ce .p12fichier, il est chargé dans votre trousseau de connexion.

Vous verrez que ce certificat est valide pour un an, "Émis par: Autorité de certification des relations de développeurs Apple dans le monde entier". Je soupçonne que c'est plus digne de confiance qu'un certificat auto-signé.

Maintenant, vous pouvez signer votre application comme avant avec codesign -f -s <apple_ID> /path/to/prog. Je l'ai essayé avec un simple binaire (compilé à partir de hello.c:-)), et cela a pu être vérifié avec codesign -v.

Je n'ai pas encore essayé avec les packages Python, aussi je n'ai aucun conseil à donner aux personnes qui ont mentionné dans leurs commentaires que cela ne peut pas signer "python.app".

Cela concerne si l'application est signée ou non. Si ce n'est pas signé, la préférence ne sera pas mémorisée.

Pour voir si une application est signée, faites-le dans Terminal:

cd path/to/your/app
codesign -vvv Eclipse.app/

Pour Eclipse - le mien dit que ce n'est pas signé du tout. Je ne peux pas en dire plus sur la façon de signer l'application car je ne me suis pas donné la peine de le faire, mais la réponse fournie par le superutilisateur la couvre:

https://superuser.com/questions/100013/why-does-the-mac-os-x-firewall-dialog-recurringly-pop-up-and-disappear-by-itself#300841

Remarque: si vous utilisez un environnement virtuel, veillez à signer l'application utilisée pour l'environnement. Je sais que cela est évident, mais devait être dit quand même.

Je comprends que c’est un vieux Q & A, mais c’était le premier succès sur Google lorsque j’ai eu le même problème. Je voulais juste ajouter quelque chose pour les autres qui pourraient atterrir ici.

Pour exécuter l'une des commandes codesign décrites ici, il est nécessaire que les outils de ligne de commande xcode soient installés. Sans ceux-ci, on obtient un message d'erreur:

xcrun: error: invalid active developer path (/Library/Developer/CommandLineTools), missing xcrun at: /Library/Developer/CommandLineTools/usr/bin/xcrun

Pour résoudre ce problème, installez les outils avec:

xcode-select install

J'aurais commenté le post de ahall, mais je n'ai pas les points de réputation pour le faire.

J'ai eu cette boîte de dialogue (Canon ccpd) à chaque fois après le démarrage de mon ordinateur. Ouvrez le pare-feu> sécurité et confidentialité> déverrouillez pour activer les modifications> cliquez sur le bouton "Activer le mode furtif"> cliquez sur le bouton "Bloquer toutes les connexions entrantes".

Plus de boîte de dialogue irritante du pilote d'imprimante Canon après cela.

J'ai essayé tout ce qui précède dans Mac 10.13 et rien n'a fonctionné.

En fin de compte, j’ai écrit un script qui s’exécutait lors de la déconnexion et qui était associé au hook de connexion et qui désactivait le pare-feu. Ainsi, lorsqu’il était connecté, il n’avait plus besoin de permission, puis en utilisant delaylauncher, un autre script activait le pare-feu.

Tout va bien maintenant

Ma situation concerne deux copies d’Eclipse installées sur MacOS Mojave 10.14.5. La première copie a été autorisée avec le pare-feu MacOS. La deuxième copie présentera toujours l'invite "accepter les connexions entrantes". Choisir "Accepter" continuerait à présenter le message après chaque redémarrage, apparemment, le réglage du pare-feu n'était pas mis à jour.

La solution consistait à ouvrir Préférences Système MacOS -> Sécurité et confidentialité -> Pare-feu, déverrouiller l’écran, Options du pare-feu. Sélectionnez Eclipse.app "Autoriser les connexions entrantes" et supprimez-le avec le bouton "-". La prochaine fois que j'ai sélectionné "Autoriser", l'invite "Accepter les connexions entrantes" d'Eclipse était la dernière.

La solution pour moi était de simplement désactiver complètement le pare-feu. Il est extrêmement courant de créer des logiciels Web qui ne sont bien sûr pas signés parce que vous les compilez de manière native.

Ouvrez le projecteur avec la barre d'espacement CMD +, recherchez "privacy" et sélectionnez "Sécurité et confidentialité". Puis passez à l'onglet "Pare-feu" et désactivez le pare-feu.