Problèmes avec mirror.php

Depuis ce matin j’ai deux soucis avec mirror.php.

Le premier est qu’en lançant le script comme tous les jours, j’obtiens 0 repos dans les organisations :

API non accessible (url: https://git.spip.net/api/v1/orgs/spip-contrib-squelettes/repos?limit=50)
# 0 repositories dans https://git.spip.net/spip-contrib-squelettes

Ce qui est bizarre c’est qu’en lançant ce script à partir de PHPStorms, je n’ai plus l’erreur et tout se déroule correctement. D’ailleurs si j’essaye l’URL avec Firefox j’obtiens bien la liste des repos de l’organisation concernée.

Le deuxième concerne 13 repos de spip-contrib-extensions. J’ai donc lancé le script pour recréer un environnement complet en local et là j’obtiens la liste des erreurs suivantes:

    13 Repositories en erreur
    - git@git.spip.net:spip-contrib-extensions/opquast.git
    - git@git.spip.net:spip-contrib-extensions/select2.git
    - git@git.spip.net:spip-contrib-extensions/auteur_nom_prenom.git
    - git@git.spip.net:spip-contrib-extensions/porte_plume_intertitres.git
    - git@git.spip.net:spip-contrib-extensions/newsletters_modeles.git
    - git@git.spip.net:spip-contrib-extensions/datatables.git
    - git@git.spip.net:spip-contrib-extensions/jQuery_number.git
    - git@git.spip.net:spip-contrib-extensions/cartes_choroplethes.git
    - git@git.spip.net:spip-contrib-extensions/formidable_identification.git
    - git@git.spip.net:spip-contrib-extensions/chats.git
    - git@git.spip.net:spip-contrib-extensions/depublication.git
    - git@git.spip.net:spip-contrib-extensions/aspirateur.git
    - git@git.spip.net:spip-contrib-extensions/dd.git

J’ai regardé les paramètres des repos mais je n’ai pas trouvé un point commun qui expliquerait l’erreur qui est la suivante pour chacun des repos :

git clone git@git.spip.net:spip-contrib-extensions/datatables.git spip-contrib-extensions/datatables
Cloning into 'spip-contrib-extensions/datatables'...
kex_exchange_identification: Connection closed by remote host
fatal: Could not read from remote repository.

Please make sure you have the correct access rights
and the repository exists.

Je ne vois vraiment d’où viennent ces deux problèmes.
Si quelqu’un a une idée ?

Un problème avec https et le certificat racine qui a expiré le 30 octobre ?
Cela impacte un certain nombre de processus de type curl ou ssh sur les machines pas à jour…


Cédric
Le 3 oct. 2021 à 13:03 +0200, Eric Lupinacci via Discuter de SPIP noreply@discuter.spip.net, a écrit :

Eric Lupinacci eric_tonton
Octobre 3
Depuis ce matin j’ai deux soucis avec mirror.php.
Le premier est qu’en lançant le script comme tous les jours, j’obtiens 0 repos dans les organisations :
API non accessible (url: https://git.spip.net/api/v1/orgs/spip-contrib-squelettes/repos?limit=50)

0 repositories dans Squelettes SPIP - SPIP on GIT

Ce qui est bizarre c’est qu’en lançant ce script à partir de PHPStorms, je n’ai plus l’erreur et tout se déroule correctement. D’ailleurs si j’essaye l’URL avec Firefox j’obtiens bien la liste des repos de l’organisation concernée.
Le deuxième concerne 13 repos de spip-contrib-extensions. J’ai donc lancé le script pour recréer un environnement complet en local et là j’obtiens la liste des erreurs suivantes:
13 Repositories en erreur

J’ai regardé les paramètres des repos mais je n’ai pas trouvé un point commun qui expliquerait l’erreur qui est la suivante pour chacun des repos :
git clone git@git.spip.net:spip-contrib-extensions/datatables.git spip-contrib-extensions/datatables

Cloning into ‹ spip-contrib-extensions/datatables ›…

kex_exchange_identification: Connection closed by remote host

fatal: Could not read from remote repository.

Please make sure you have the correct access rights

and the repository exists.

Je ne vois vraiment d’où viennent ces deux problèmes.
Si quelqu’un a une idée ?
Voir le sujet ou répondre à ce courriel pour répondre.
Vous recevez ce courriel car vous avez activé la liste de diffusion.
Pour se désabonner de ces courriels, cliquez ici.

Je viens de tester sous Windows 10 : même problème : tout à 0.
Alors que git pull en ligne de commande fonctionne sans problème.

Comment on se sort de ce problème ?
C’est le serveur ou mon ordi qui doit être mis à jour ?

J’ai mis à jour mon git en 2.33, mon MAMP PRO en 6.5 et j’ai même eu une notification pour une petite mise à jour de Big Sur. Pour l’instant rien n’y fait, toujours le problème avec l’API gitea à priori. Je pencherais plutôt pour le curl que pour le ssh car le checkout fonctionne en ssh.
Par contre, je ne sais pas quoi faire pour le curl ?

Update de curl en 7.79 : pas mieux. Donc là je ne sais plus.

Pareil… Je n’ai aucune mise à jour disponible et je suis bloqué avec mirror.php
Alors je veux bien que le problème soit chez moi… Mais git fonctionne sur mon environnement (W10)

Pour colmater provisoirement ce problème de curl, on peut ajouter :
curl_setopt($ch, CURLOPT_SSL_VERIFYPEER, 0); en ligne 276

1 « J'aime »

Yep, ça fonctionne dans ce cas en lançant le script par le terminal. En outre, les 13 repos qui étaient en erreur ont bien été clonés.

Y aurait-il un rapport entre ce sujet et celui que j’ai ouvert ici : Mises à jour impossibles sous MAMP ?

Tout à fait, c’est le même problème et le lien donné par RealET est bien utile

Pour faire court : curl considère qu’une url HTTPS est insécure si un seul des certificats est invalide. Du coup toute URL ssl ton le certificat mentionne encore le vieux certificat invalide dans la chaine est bloquée par curl.
Le vieux certificat est encore dans la chaine parce que c’était supposé permettre aux vieux terminaux de continuer à accèder aux URLs let’sencrypt, mais il semble bien qu’au final il y a une erreur de design…

Oui merci pour les retours, j’ai bien regardé le post mentionné et «purgé» le certificat incriminé ( DST Root CA X3), pourtant, comme je l’indique, un CURL depuis le terminal OSX (en local) sur le HTTPS de SPIP fonctionne, mais depuis SVP (local MAMP) le chargement d’un plugin en HTTPS échoue, et fonctionne en HTTP.

pour résoudre le problème dans MAMP il faut modifier son cacert également :

$ diff /Applications/MAMP/Library/OpenSSL/certs/cacert.pem-avantedit /Applications/MAMP/Library/OpenSSL/certs/cacert.pem
517,536d516
< DST Root CA X3
< ==============
< -----BEGIN CERTIFICATE-----
< MIIDSjCCAjKgAwIBAgIQRK+wgNajJ7qJMDmGLvhAazANBgkqhkiG9w0BAQUFADA/MSQwIgYDVQQK
< ExtEaWdpdGFsIFNpZ25hdHVyZSBUcnVzdCBDby4xFzAVBgNVBAMTDkRTVCBSb290IENBIFgzMB4X
< DTAwMDkzMDIxMTIxOVoXDTIxMDkzMDE0MDExNVowPzEkMCIGA1UEChMbRGlnaXRhbCBTaWduYXR1
< cmUgVHJ1c3QgQ28uMRcwFQYDVQQDEw5EU1QgUm9vdCBDQSBYMzCCASIwDQYJKoZIhvcNAQEBBQAD
< ggEPADCCAQoCggEBAN+v6ZdQCINXtMxiZfaQguzH0yxrMMpb7NnDfcdAwRgUi+DoM3ZJKuM/IUmT
< rE4Orz5Iy2Xu/NMhD2XSKtkyj4zl93ewEnu1lcCJo6m67XMuegwGMoOifooUMM0RoOEqOLl5CjH9
< UL2AZd+3UWODyOKIYepLYYHsUmu5ouJLGiifSKOeDNoJjj4XLh7dIN9bxiqKqy69cK3FCxolkHRy
< xXtqqzTWMIn/5WgTe1QLyNau7Fqckh49ZLOMxt+/yUFw7BZy1SbsOFU5Q9D8/RhcQPGX69Wam40d
< utolucbY38EVAjqr2m7xPi71XAicPNaDaeQQmxkqtilX4+U9m5/wAl0CAwEAAaNCMEAwDwYDVR0T
< AQH/BAUwAwEB/zAOBgNVHQ8BAf8EBAMCAQYwHQYDVR0OBBYEFMSnsaR7LHH62+FLkHX/xBVghYkQ
< MA0GCSqGSIb3DQEBBQUAA4IBAQCjGiybFwBcqR7uKGY3Or+Dxz9LwwmglSBd49lZRNI+DT69ikug
< dB/OEIKcdBodfpga3csTS7MgROSR6cz8faXbauX+5v3gTt23ADq1cEmv8uXrAvHRAosZy5Q6XkjE
< GB5YGV8eAlrwDPGxrancWYaLbumR9YbK+rlmM6pZW87ipxZzR8srzJmwN0jP41ZL9c8PDHIyh8bw
< RLtTcm1D9SZImlJnt1ir/md2cXjbDaJWFBM5JDGFoqgCWjBH4d1QB7wCCZAA62RjYJsWvIjJEubS
< fZGL+T0yjWW06XyxV3bqxbYoOb8VZRzI9neWagqNdwvYkQsEjgfbKbYK7p2CNTUQ
< -----END CERTIFICATE-----
<

et en enlevant ces lignes donc, SPIP arrive à nouveau à récupérer un dépot dans SVP et tout le toutim

Oui confirmé, pour les gens sous macos : il faut donc enlever le certification DST Root CA R3 de /etc/ssl/cert.pem et pour ceux qui utilisent MAMP et le PHP de MAMP en ligne de commande supprimer ce certificat du fichier /Applications/MAMP/Library/OpenSSL/certs/cacert.pem

et la méthode pour « forcer » la mise à jour sur les serveurs Debian/Ubuntu :

Et sur Laragon, j’ai fait ceci (sauf le 5) : https://forum.laragon.org/topic/1600/err_ssl_key_usage_incompatible-default-ssl-in-laragon/10

  1. stop Apache
  2. open this files and edit:
    laragon\bin\laragon\tpl\openssql.conf.tpl
    laragon\usr\tpl\openssql.conf.tpl
    laragon\etc\ssl\openssql.conf
  3. in all files change "keyUsage= … " to:
    4.keyUsage = nonRepudiation, digitalSignature, keyEncipherment*
  4. start Apache
  5. Click Menu > Apache > SSL > Add laragon.crt to Trust Store

Confirmation ici aussi : tout fonctionne nickel !
Merci à tous pour votre aide.

Installation perso avec homebrew sur un vieux mac tournant sur 10.13.6, une fois nettoyé le certificat présent dans /usr/local/etc/openssl/cert.pem tout refonctionne proprement !
Merci
++

Merci Cerdic, en local, j’ai fait cette manip dans MAMP et toue est revenu dans l’ordre. Par contre, mon serveur distant est un mac mini sous CAPITAN, etj’ai beau chercher, je ne trouve pas de /etc/ssl/cert.pem. Par contre, j’ai un /etc/certificates plein de certificats divers, dont ceux de mon domaine moulliac.fr (spip 3.2.19)
Je ne suis pas familier du tout de ces manips et il est impossible de faire des mises à jour des plugins. Peut-être pourrais-tu me donner des pistes ? Je t’en remercie d’avance.
Marc