0
votes

Dois-je nettoyer le mot de passe de l'historique de validation de branche si je fais une fusion squash?

J'ai accidentellement commis un mot de passe dans une branche de fonctionnalité et synchronisé cette branche avec la télécommande. J'ai essayé de nettoyer l'historique de commit de branche avec bfg sans succès et avec git-filter-repo j'ai d'autres problèmes.

J'ai maintenant validé le fichier de paramètres sans le mot de passe à la succursale.

Si je fusionne la branche de fonctionnalité avec la branche source avec squash merge et supprime la branche de fonctionnalité, cela supprimera-t-il effectivement le mot de passe de tout l'historique de git?


4 commentaires

squash merge ne conserverait que le dernier commit dans l'historique visible, vous pouvez également supprimer le fichier avec git rebase -i . Je ne sais pas comment git gère cela sur le serveur, mais cela prendra probablement un certain temps avant que votre validation de mot de passe ne soit récupérée et vous devriez quand même considérer le mot de passe comme compromis.


La fusion de squash et la suppression de branche supprimeront les validations de l'historique du dépôt (et finiront probablement par purger les validations orphelines), mais si vous utilisez des outils côté serveur pour le faire dans une requête Pull / Merge, l'historique des validations de cette requête peut être retenu. Voir ma réponse pour une approche plus simple.


@ian était d'accord. Je pense que le rebase interactif est la voie à suivre ici.


S'agit-il d'un dépôt public ou privé au sein de votre organisation? Est-il possible de faire confiance à tous ceux qui ont accès au repo?


3 Réponses :


0
votes

Il semble que jusqu'à présent, le mot de passe se trouve uniquement sur votre branche de fonctionnalité locale et sur la branche de fonctionnalité distante. Le moyen le plus simple de le supprimer est de s'en débarrasser localement, puis de le repousser de force. Utilisez modifier ou rebase interactif pour réécrire la validation localement sans le mot de passe, puis forcez la sortie de votre branche. À ce stade, le commit restera masqué sur le serveur jusqu'à ce qu'il soit récupéré, et le temps que cela prend dépend du serveur. (Certains clients git par défaut à 60 jours mais il est impossible de savoir ce que votre serveur utilise par défaut sans plus d'informations.)

Notez que si vous avez déjà créé une demande d'extraction / fusion avec la branche qui contenait la validation avec le mot de passe, alors le serveur peut conserver indéfiniment l'historique des validations incluses. Pour cette raison, j'éviterais la fusion de squash au moment de la demande d'extraction / fusion, car cela peut conserver l'historique des validations pendant longtemps.

Si votre référentiel est public, vous devez supposer que le mot de passe a déjà été compromis et vous devez le modifier immédiatement. En fait, c'est probablement l'option la plus sûre, même dans un dépôt privé, à moins que vous ne soyez d'accord avec le partage avec vos collaborateurs.


1 commentaires

J'adorerais que quelqu'un explique la DV ici. Je suppose que mon troisième paragraphe n'était pas le premier?



0
votes

Commençons par aller droit au but:

Ce mot de passe a été compromis. Il n'y a aucun moyen pour vous de tracer où il aurait pu aller après l'avoir poussé vers la télécommande. Vous ne pouvez pas remettre ce génie dans la bouteille; la seule chose sûre à faire est de changer le mot de passe.

Cela rend le reste de la discussion essentiellement académique. Soit le mot de passe ne sera pas changé et le supprimer de l'historique est une mesure insuffisante, soit il sera changé et le supprimer de l'historique est cosmétique.

Néanmoins, pour répondre à votre question directe:

Si je fusionne la branche de fonctionnalité avec la branche source avec squash merge et supprime la branche de fonctionnalité, cela supprimera-t-il effectivement le mot de passe de tout l'historique de git?

Pas vraiment. Pour supprimer complètement les données de votre référentiel local, vous devez vous assurer que le (s) commit (s) le contenant sont inaccessibles de toutes les références ainsi que du reflog, puis vous devrez forcer le garbage collection. Pour vraiment le supprimer de la télécommande, des procédures similaires sont nécessaires, mais la manière dont ce type de gestion interne est géré varie en fonction de la façon dont le dépôt est hébergé.

Et encore une fois, tout cela supposerait que personne n'avait déjà récupéré une référence dont l'historique contient le mot de passe. S'ils l'ont fait, rien de ce que vous pouvez faire ne les forcera à le jeter.


2 commentaires

Le reflog ne serait-il probablement pas uniquement sur la machine de l'utilisateur? (Sauf s'il s'agit d'un dépôt public, alors qui sait ...) J'agis en supposant que la machine de l'utilisateur est sécurisée.


Quelqu'un a également DV a cette réponse? Cette réponse me semble parfaitement raisonnable, tout comme ma réponse. Quelqu'un doit apporter des précisions ici.



1
votes

Ce que j'ai finalement fait était

  • pour révoquer le mot de passe dans le système cible
  • supprimer le mot de passe du code avec un nouveau commit
  • ajouter dans le commentaire que le mot de passe vu précédemment avait été modifié

Mieux vaut ne pas être paresseux avec vos erreurs, mais prenez les mesures nécessaires pour changer le mot de passe.


0 commentaires