C'est la porte ouverte à une attaque de type supply chain
attack. Parce qu'un attaquant peut récupérer le domaine mettre
en place une copie de l'existant sauf qu'il te donne son code
par exemple.
Oui, bien sur. Mais:
- un nom de domaine qui expire n'est normalement pas automatiquement disponible, donc tu va avoir un souci visible assez vite si tu as une CI, etc. Ensuite, je suppose que tout les registrars ne sont pas Gandi.
un certificat qui expire ne va pas automatiquement résulter en une compromission. Les MITM restent quand même assez rare en pratique. Je pense que ça requiert des moyens assez importants en général digne d'un état, tout en étant non utilisable pour ce qu'un état va avoir besoin (cad d'une cible précise avec un timing précis, et idéalement, ne pas se faire choper).
mais qu'avoir comme politique de fuir les projets qui sont sur
gitlab n'est pas une solution. Tous les projets qui sont
sensibles à ce genre de problème peut poser des problèmes
quelques soit là où il est hébergé.
Clairement, ça me parait contre productif, je suis d'accord.
Ensuite, il y a une échelle des risques, et la, gitlab risque de grimper d'un échelon. Le bon coté, c'est qu'il me parait facile de vérifier si une de tes dépendances va disparaître de gitlab via leur API.
[^] # Re: Pire des options
Posté par Misc (site web personnel) . En réponse au lien GitLab plans to delete dormant projects in free accounts. Évalué à 3.
non, mais c'est le critère annoncé par Gitlab.
Oui, bien sur. Mais:
- un nom de domaine qui expire n'est normalement pas automatiquement disponible, donc tu va avoir un souci visible assez vite si tu as une CI, etc. Ensuite, je suppose que tout les registrars ne sont pas Gandi.
Clairement, ça me parait contre productif, je suis d'accord.
Ensuite, il y a une échelle des risques, et la, gitlab risque de grimper d'un échelon. Le bon coté, c'est qu'il me parait facile de vérifier si une de tes dépendances va disparaître de gitlab via leur API.