Salut,
mon plugin blocks est en erreur 500 :
https://git.spip.net/spip-contrib-extensions/blocks/
Je peux le cloner en local, mais pas y accéder par Gitea, y compris les tickets (j’ai des urls dans l’historique, genre https://git.spip.net/spip-contrib-extensions/blocks/issues/10 qui sont en 500 aussi).
Qué pasa ?
Je le signalais à l’instant sur IRC pour les repos https://git.spip.net/spip-galaxie/trad.spip.net & https://git.spip.net/spip-contrib-outils/yara-spip (et certainement plein d’autres).
Ok merci.
J’en avais checké une dizaine parmi les derniers qui avaient bougé et pas vu d’erreurs.
Mais effectivement c’est plus généralisé :-/
j’ai eu une erreur 500 au moment de la création du repos bacasable pendant la formation… joie 
Arf, super pratique.
Bon, au moins je peux pusher, le dépôt ne semble pas altéré…
Hello,
Soucis ici par exemple https://git.spip.net/spip-contrib-extensions/couteau_suisse
https://git.spip.net/spip-contrib-extensions/cvt-upload
Une idée @azerttyu ?
Merci
Hello
En effet étrange. Historiquement on peut encore avoir des 500 sur certains dépôts, suite à un très vieux incident serveur. Il doit en rester 2 ou 3 dans ce goût car personne n’a de copie à jour de l’époque. Ce cas est donc à la marge.
Pour les cas présents; à mon niveau, ce qui est effectivement pas du tout normal :
Cela semble indépendant de l’état authentifié. Je regarde les journaux pour voir.
L’interface étant un client git avec un cache web cela ne présuppose par de l’état du dépôt à proprement parler.
Hello,
I am experiencing also an issue and it is severe as I have been pulling the ecran_securite.php with a cron job. based on the spip documentation.
As the repository was down with error 500, the ecran_securite then became a html page.
This faulty ecran_securite then broke one of my sites. On visit of the site, users would instead of the site see the html of the broken spip git server, and an alert box: « Failed to load asset files from https://site/assets/js/index.js?v=1.19.2. Please make sure the asset files can be accessed. »
ecran_security es extremely sensitive, and it seems important to change the cronjob to not accept the file unless it comes with a response 200, not 5xx or other.
Perhaps there is another solution? In any case I propose to update the spip documentation on ecran_securite to warn that cronjobs need to avoid issues caused by error 500.
The cronjob I currently have is:
curl https://git.spip.net/spip-contrib-outils/securite/raw/branch/master/ecran_securite.php --output /var/www/html/config/ecran_securite.php
Notes: This cronjob I already improved from a previous one that used wget. Using wget, if there is an error 400, wget will overwrite the ecran_securite file with an empty file. This is why I switched to curl. Curl however will still accept response code 5XX and place a potentially faulty file on the server.
Best regards,
Urs
Bonjour
La cause est identifiée. Un script qui a tourné en boucle et saturé l’espace alloué.
Je fais une purge du coupable.
Bonjour
Le problème est normalement résolu. Je dois rajouter des points de contrôle pour éviter l’emballement sur certains script et saturer le serveur.
Il y aura donc encore des coupures ponctuelles dans la journée.
Et encore désolé pour l’incident
Merci pour votre réaction rapide et pour l’avoir corrigé.
Hello dear community,
I would like to follow up on this question.
What is the recommended cronjob to update ecran_securite?
In my opinion, the cronjob should be such that
I currently have this:
curl https://git.spip.net/spip-contrib-outils/securite/raw/branch/master/ecran_securite.php --output /var/www/html/config/ecran_securite.php
However, it does not satisfy point (2). When the gitlab went down, ecran_securite.php was replaced with the html that gitlab provided, making lots of sites look like an error page, and also essentially disabling the ecran_securite.php file (as contents were replaced). I think it is because gitlab showed an error 5XX, but it did not submit this with a proper header.
Whatever it is, the URL on which ecran_securite.php file is hosted is quite critical and I think the cronjob should have some redundancy built-in.
Kind regards
Hello
I do as this : spip_cleaner/clean_spip.sh at master - spip_cleaner - SPIP on GIT
Or from alternc-spip package with a more secure appproach : https://github.com/AlternC/alternc-spip/blob/main/src/usr/lib/alternc/update_spip_ecran_securite.sh
I hope to have been undestood the inital question
Hello,
and yes, the this implementation of the update script is solving the issue:
As far as I see it checks for an empty response, as well as comparing the download to the hash of the file to check integrity.
Thank you.
Kind regards
Hello
Yes you’ve understood correctly. We us blob content from api to retrieve some extra data as hash fingerprint content.
This hash is generated from git hash-object command.
Following previous code you could do also git hash-object "${ecran_securite_file_path}" and compare hash.
In this case you must have an other source to compare fingerprint.
As API provide all content with one query , I prefer to use it to calculate local hash and compare them
cf Check file integrity before to save it · AlternC/alternc-spip@e3becff · GitHub
Ok, this is good.
We could provide this as the recommended procedure in critical environments.
I’ve just created an account on spip.net.
Do you think it is wise to propose an edit on these pages, about creating the right type of cronjob?
Kind regards
Hello
Yes, you can use forum part on these pages to propose any improvement. It’s a very nice idea.
Will be better as we have yet hijack this thread twice 
Have a nice day
Hello,
It seems with the migration of spip code to gitlab yet again the URL of the ecran_securite file has changed.
This used to work:
curl -f https://git.spip.net/spip-contrib-outils/securite/raw/branch/master/ecran_securite.php -o /var/www/html/config/ecran_securite.php
But after the migration, the URL of ecran_securite has slightly changed.
Now from this page: Écran de sécurité - SPIP
I can see the URL should be
Error 403: Forbidden
Hence this would be the correct cronjob:
curl -L -f https://git.spip.net/spip-contrib-outils/securite/-/raw/master/ecran_securite.php -o /var/www/html/config/ecran_securite.php
Another option (as adjusted above for future changes of this URL) is to add to the curl line the option -L
curl -L
So that the redirect is followed. Without it, it will result in an ecran_securite with the following contents, which are then included to every spip page.
<html>
<head><title>301 Moved Permanently</title></head>
<body>
<center><h1>301 Moved Permanently</h1></center>
<hr><center>nginx/1.22.1</center>
</body>
</html>
And as it is I am not sure how this approach would need to be modified:
This seems to be the best approach to prevent faulty ecran_securite.php files from being installed by cron.
I think a proper documentation should be provided on the ecran_securite page to use curl -L. There should also be an way to not complete the download when there is an error 5x, 4x, 3x, which has been an issue before (5xx error page that was shown but without a 5xx header, hence the file was still downloaded).
You should open an issue here : Tickets · spip-contrib-outils / Gitea To Gitlab Migration · GitLab with all the details you provided here.
The raw url in Écran de sécurité - SPIP has been corrected.
For the curl part, this is not a code from SPIP documentation, it seems.