Interrogando qualsiasi altro feed da WordPress tutto funziona regolarmente ma considerando che GitHub fornisce i suoi feed RSS su protocollo sicuro http (HTTPS), ne ho dedotto che il problema fosse proprio nel certificato.

Forse perchè l’authority per la certificazione non risulta tra quelle previste dal server su cui risiede WordPress, oppure perchè c’è una qualsiasi altra configurazione del server che non consente una validazione del Certificato di Sicurezza, il risultato è che non sarebbe possibile interrogare un feed RSS di GitHhub, ottenendo in compenso questo simpatico messaggio di errore:

RSS Error:
WP HTTP Error: SSL certificate problem, verify that the CA cert is OK.
Details: error:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed

Ma come ben sapete “non è possibile” non fa parte del mio vocabolario, quindi mi sono spulciato il codice della classe Http di WordPress e facendo un po’ di reverse engignering sono arrivato alla soluzione del problema.

Per evitare che WordPress faccia la verifica del certificato basta mettere nel file functions del proprio tema questa semplice riga di codice:

add_filter('https_ssl_verify', '__return_false');

Per riuscire però ad effettuare i commit attraverso il Proxy che non consente l’acceso ssh al server github.com ho fatto diverse ricerche su internet, provando le più diverse strade.

C’era chi suggeriva di creare un file wrapper per il proxy seguendo un procedimento alquanto semplice:

• Installare netcat
• creare uno script da shell collocandolo nella directory bin/ dell’utente che riportava in sintesi questo comando “nc -x${PROXY_IP}:${PROXY_PORT} -X5 $*“
• configurare il parametro core.gitproxy indicando il nome del file precedentemenet creato.

Per me non ha funzionato e comunque questa procedura a mio avviso poteva essere  semplificata ulteriormente utilizzando questi due semplici comandi eseguiti da shell.

EXPORT http_proxy=http://myproxy:8080
EXPORT https_proxy=http://myproxy:8080

Non li metterei come valori persistenti perchè, usando il notebook su diverse reti rischierei di non raggiungere il proxy specificato con conseguenza dell’interruzione della navigazione.

Comunque non ha funzionato. Quindi ho cercato una nuova soluzione al problema.

Un altro sito suggeriva di usare l’url proposto da github nella versione https al posto di quello ssh.

Ho fatto un tentativo e non riuscivo nemmeno a clonare il repository remoto ricevendo come risposta “warning: remote HEAD refers to nonexistent ref, unable to checkout.“. Quindi ho temuto che fosse un problema del mio repository remoto. Per fortuna anche con il repository di JQuery mi segnalava lo stesso errore. E lo faceva con qualsiasi repository provassi a clonare. Quindi il repository non aveva problemi.

Ho provato a fare un mix tra le soluzioni “installazione netcat” e “https al posto di ssh” ma comunque non ho avuto il risultato sperato quindi ho continuato nella ricerca della soluzione fino ad incappare in questa discussione!

Grazie a quanto è scritto nella discussione precedente ho cominciato a fare un po’ di prove giocando sull’url per la richiesta del repository.

La soluzione in fondo era più semplice di quanto si pensasse.

Partendo dall’url di aggiornamento del repository fornito da github in formato https (https://user@github.com/user/repository.git), ho inserito anche la password dell’account github e ho fatto viaggiare la richiesta su protocollo http (non sicuro). Quindi l’url utilizzato in fine è stato:

http://user:password@github.com/user/repository.git

In questo modo ha funzionato tutto correttamente e sono libero di aggiornare il mio framework da, come direbbero gli americani, “ognidove”! :)