Confirmación eliminada aún visible desde la interfaz web de GitLab, exponiendo datos confidenciales [cerrado]

1

Hace algunas semanas, accidentalmente cometí un archivo de configuración que contenía algunas contraseñas y lo inserté en un control remoto de GitLab gestionado por mi empresa.

Después de eso utilicé BFG Repo-Cleaner para eliminar las contraseñas del historial.

Después de la limpieza ejecuté:

git reflog expire --expire=now --all && git gc --prune=now --aggressive
git push --force

He visto que se han cambiado los hashes de confirmación y se han eliminado datos confidenciales (puedo ver que tanto utilizando la interfaz web de GitLab como explorando un nuevo clon del repositorio).

Sin embargo, si accedo a una de las páginas antiguas que llaman directamente a la URL ( https://<my-company>/gitlab/test-bfg/commit/<theoretically-unexisting-hash> ), puedo ver un gitdiff de una confirmación que contiene las contraseñas. Descubrí esto accidentalmente, navegando en el historial del navegador.

Si trato de verificar el mismo hash en el repositorio recién clonado, obtengo este mensaje:

fatal: reference is not a tree: d7fb999c...

Entonces, si una persona clona ese repositorio de GitLab I pienso no puede ver ese commit *, sin embargo, todavía es visible desde la interfaz web, si uno pudiera adivinar un antiguo hash.
* De todos modos, me sentiría más cómodo leyendo did not match any file(s) known to git en lugar de reference is not a tree .

No creo que este sea un tipo de problema de caché, porque lo intenté nuevamente después de algunas horas.

Entonces, las preguntas son:

  • ¿Por qué sucede esto? ¿Estoy usando las herramientas de manera incorrecta?
  • ¿Hay algunas formas de ver los hashes ocultos?
  • ¿Alguna vez experimentó esto, tal vez usando diferentes sistemas (GitHub, BitBucket)?

Muchas gracias.

    
pregunta xonya 08.09.2017 - 00:15
fuente

2 respuestas

2

git gc solo afecta su copia local y el siguiente git push no propagará ninguna instrucción para la recolección de basura al sitio remoto. Vea también ¿Cómo puedo activar la recolección de basura en un ¿Git repositorio remoto? y Eliminando datos confidenciales de un repositorio (en github) . Y mientras que el último le ayuda a eliminar algunos datos confidenciales, también contiene una advertencia clara de las limitaciones de este enfoque:

  

Advertencia: Una vez que haya enviado un compromiso a GitHub, debe considerar comprometidos todos los datos que contiene.
  ... las confirmaciones pueden seguir siendo accesibles en cualquier clones o bifurcaciones de su   repositorio, directamente a través de sus hash SHA-1 en vistas en caché en GitHub,   ya través de cualquier solicitud de extracción que haga referencia a ellos. No puedes hacer   nada sobre clones o forks existentes de su repositorio, pero usted   puede eliminar permanentemente todas las vistas en caché de su repositorio y extraer   solicite en GitHub poniéndose en contacto con el servicio de asistencia de GitHub.

Y aunque esto es de Github, probablemente sea similar en Gitlab.

    
respondido por el Steffen Ullrich 08.09.2017 - 07:23
fuente
2

No estoy muy familiarizado con Gitlab o con lo que hace el limpiador de repo BFG. Pero siempre es una buena idea rotar sus contraseñas cuando se han expuesto en público. Si se trata de un repositorio público, no hay forma de saber de manera confiable si alguien ha comprobado las antiguas confirmaciones de git. Dicho esto, presente una solicitud de soporte con GitLab también, por si acaso.

    
respondido por el eternaltyro 08.09.2017 - 05:39
fuente

Lea otras preguntas en las etiquetas