• [^] # Re: macOS ou quand la fin du support d’une version coïncide avec l’expiration d’un certificat racine

    Posté par (site web personnel, Mastodon) . En réponse au journal Certificat expiré. Évalué à 2.

    Il y a aussi git config --global http.sslVerify false ce qui écrit ceci dans ~/.gitconfig:

    [http]
     sslVerify = false
    

    Mais euh, non. 🛑 (← ceci est sensé représenter un panneau stop)

    Non, ça c’est vraiment un dernier recours, comme je l’ai indiqué il y a moyen de spécifier dans Git une autorité spécifique pour un serveur git en particulier. Et ça, on peut y faire confiance :

    [http "https://gitlab.gnome.org"]
     sslCAInfo = ${HOME}/isrgrootx1.pem
     sslVerify = true
    

    Avec la méthode que je donne, git continuera d’interrompre la connexion s’il y a un Man-In-The-Middle, alors qu’il ne le fera pas en désactivant la vérification, ce qui me rendrait vulnérable et donc par effet de bord, rendrait vulnérable les utilisateurs des logiciels que je compile éventuellement. J’imagine que la référence du commit de HEAD ne peuts probablement pas être falsifiée facilement (peut-être aussi difficilement que de faire un faux certificat qui marche, autrement dire, considéré comme raisonnablement difficile), mais j’ai pas envie de vérifier à la main à chaque clone.

    ce commentaire est sous licence cc by 4 et précédentes