make, ping et nc : des codes de sortie qui, discrètement, ne vérifient pas ce qu'on croit

Ce que c'est

Trois outils qu'un agent appelle souvent via le shell ont chacun un code de sortie dont le sens est facile à mal supposer.

make : "GNU make exits with a status of zero if all makefiles were successfully parsed and no targets that were built failed. A status of one will be returned if the -q flag was used and make determines that a target needs to be rebuilt. A status of two will be returned if any errors were encountered." Hors -q, le code 1 n'apparaît pas lors d'un build ordinaire : l'échec d'une recette produit le code 2 ; le Error 1 affiché dans le message de make est le code de la recette, pas celui de make.

ping : "If ping does not receive any reply packets at all it will exit with code 1 ... On other error it exits with code 2. Otherwise it exits with code 0." Le code 1 signifie que ping fonctionne correctement et signale l'absence de réponse : hôte éteint, paquets rejetés par un pare-feu, ou adresse erronée qui se résout pourtant. Le code 2 est réservé aux dysfonctionnements de ping lui-même (arguments invalides, nom non résolu, problèmes de permissions).

nc/ncat : les implémentations diffèrent et beaucoup d'entre elles (dont le netcat d'OpenBSD) ne documentent pas de table formelle des codes de sortie. Ncat, de Nmap, le fait : "The exit code reflects whether a connection was made and completed successfully. 0 means there was no error. 1 means there was a network error of some kind ... 2 is reserved for all other errors, like an invalid option or a nonexistent file." Considérez les codes de toute autre variante de nc comme non vérifiés tant que vous n'avez pas consulté sa propre documentation.

openssl s_client : son option -verify documente un piège réel : "Unless the -verify_return_error option is given, the verify operation continues after errors ... As a side effect the connection will never fail due to a server certificate verify failure." Sans cet indicateur, une session TLS menée à terme se termine avec le code 0, même si le certificat est invalide, expiré ou auto-signé.

Pourquoi c'est important

Dans chacun de ces cas, le test naïf « 0 = bon, sinon = mauvais » mène à une conclusion fausse : le mode -q de make inverse le sens habituel du code 1, le code 1 de ping est une observation réseau légitime et non le signe d'un appel erroné, et le code 0 par défaut d'openssl s_client peut vouloir dire « connecté à un attaquant présentant un certificat invalide » plutôt que « connexion vérifiée ».

Comment l'appliquer

• Avec make -q, traitez le code 1 comme le signal attendu « une reconstruction est nécessaire » et réservez la vraie gestion d'erreur au code 2.
• Utilisez la distinction 1/2 de ping pour séparer « hôte injoignable » (1, à signaler comme un problème de la cible) de « échec de ping lui-même » (2, à résoudre en vérifiant vos propres arguments).
• Préférez nc -z avec les codes documentés de votre implémentation précise, ou analysez le texte de sa sortie ; ne supposez pas que la sémantique se transpose entre le nc d'OpenBSD, GNU netcat et Ncat.
• Ajoutez toujours -verify_return_error et -verify_hostname <name> aux appels openssl s_client servant à des contrôles automatisés de certificat : sans le premier, le code 0 ne prouve rien sur le certificat, et sans le second, un certificat valide émis pour un autre nom se termine quand même avec le code 0.

Pièges

• Écrire make -q; [ $? -eq 0 ] || echo "build broken" : un code de sortie 1 avec -q signifie le contraire d'un build cassé.
• Se fier à un simple openssl s_client ... ; echo $? comme contrôle de validation du certificat.