¿Cómo empujar y extraer de github sin compartir información confidencial? ¿Difuminar y limpiar?

5 minutos de lectura

avatar de usuario
tostada de coma

Cuando extraigo de github a un repositorio del servidor, quiero evitar sobrescribir información confidencial localizada en ciertos archivos, por ejemplo, config.php.

Nota: no es un repositorio de tipo de código abierto; Tengo control total sobre el repositorio, soy el único usuario, es privado, pero de manera crítica, se basa en un marco de código abierto que podría cambiar la estructura de los archivos de configuración. Solo quiero poder extraer de él para probar, organizar y producir y no hacer que la configuración de producción termine accidentalmente en prueba, etc. Pero no puedo volver a codificar los archivos de configuración para extraer datos de otro lugar sin hacer para Situaciones de fusión difíciles más adelante si el marco se actualiza.

Idealmente Me gustaría poder decirle a Git, al extraer, durante la obtención de REPO_URI, siempre descarte cualquier parte que pueda cambiar la información que se encuentra actualmente en la línea 24 de FILE_PATH. Sin embargo, deduzco que eso no es posible (corríjanme si me equivoco).

Sin embargo a menos que alguien pueda ofrecer una forma de hacer lo anterior, lea la solución a continuación y avíseme si le parece la forma ideal de hacerlo:

Usaría la expansión de palabras clave como se describe en la guía del usuario de git aquí. A continuación, describiré cómo haría esto y luego, en la parte inferior, haré algunas preguntas sobre este enfoque.

Descripción del método

Primero, escribiría dos secuencias de comandos, “Sensible_values_inserter” y “Sensible_values_remover”, que intercambian ciertas palabras clave ficticias (que estarán en el repositorio principal de github) con la información confidencial particular, como contraseñas, nombres de usuario, rutas de bases de datos, etc.:

#! /bin/sh -f
sed -e 's/@[email protected]/dummyvalue/' -e 's/@[email protected]/dummyvalue/' $1

etc.

En segundo lugar, haría tres versiones de este script, una para cada entorno: prueba/puesta en escena/producción. Cada versión contendría las contraseñas específicas, los nombres de usuario y las rutas de la base de datos relevantes para el entorno al que pertenece, en lugar de los valores ficticios. Colocaría cada uno de estos scripts en una ruta relativa a cada uno de estos repositorios de código, así:

/live/filters/sensitive_values_inserter
/live/filters/sensitive_values_remover
/live/repo/{LIVE}
/test/filters/sensitive_values_inserter
/test/filters/sensitive_values_remover
/test/repo/{TEST}
/stag/filters/sensitive_values_inserter
/stag/filters/sensitive_values_remover
/stag/repo/{STAG}

Cada uno de estos filtros tendría los valores específicos para las configuraciones relevantes.

Luego, la configuración completa del repositorio se modificaría como tal:

$ git config filter.infosafe.smudge '../filters/sensitive_values_inserter'
$ git config filter.infosafe.clean '../filters/sensitive_values_remover'

Finalmente en el repositorio del servidor haz esto:

$ echo 'config.php filter=infosafe' >> .gitattributes

De esa manera, siempre que extraiga del servidor principal, si entiendo esto correctamente, estos filtros reemplazarán los valores “ficticios” con los que quiero usar.

Nota: para que esto funcione, como se señaló en esta otra pregunta de stackoverflow, después de configurar todo como se mencionó anteriormente, debe:

cd /path/to/your/repo
git stash save
git checkout HEAD -- "$(git rev-parse --show-toplevel)"
git stash pop

Entre el proceso de pago y el almacenamiento oculto, tuve que confirmar todos los cambios en los archivos donde se había realizado la operación de limpieza. No se preocupe, después de confirmarlos, los que están en el directorio de trabajo se manchan. (Es un poco contrario a la intuición, pero funciona).

Pude ingresar con éxito a github y solo aparecen los valores limpios.

(Existe una técnica alternativa más avanzada en este sentido que implica el uso de un .gitignore por rama, y ​​dos controladores y dos filtros por rama. Esto permite que las contraseñas activas se limpien al cambiar a la rama de prueba, y viceversa. El truco es invocar los limpiadores para ambas ramas en el .gitignore de cada rama, pero solo invocar el smudger de la rama que es el hogar del .gitignore, para que restaure la contraseña por sí mismo. Aún en este escenario, al presionar para github, toda la información confidencial permanece limpia, lo cual es bueno. Podría entrar en detalles sobre eso si alguien está interesado).

Preguntas sobre este método y alternativas

Probé esto, y funciona. Pero…

Hay una mejor manera de hacer esto usando git? Podría agregar que no es una opción simplemente ignorar los archivos que tienen información confidencial y no es una opción ignorar los cambios en ellos al fusionarlos, porque quiero poder realizar cambios en estos archivos mientras retengo ciertos valores de configuración . Es por eso que no quiero simplemente usar git update-index --assume-unchanged FILENAME para ignorar permanentemente las futuras modificaciones locales a los archivos completos.

Gracias.

  • Por si sirve de algo, el enfoque habitual (o al menos mi habitual) es no poner la información allí en primer lugar. El nombre de usuario y las contraseñas salen de ~/.netrc por ejemplo.

    – torek

    28 de agosto de 2014 a las 21:43


  • Si coloco los nombres de usuario y las contraseñas en ~/.netrc, el software ya no los tendrá.

    – Tostada de coma

    28 de agosto de 2014 a las 23:01

  • Sí, esa es la idea general, si no están en el software, no pueden terminar en ningún compromiso. El software puede recuperarlos de esos archivos (externos, proporcionados por el usuario).

    – torek

    28 de agosto de 2014 a las 23:10

  • “El software puede recuperarlos” solo si el software está programado para hacerlo, que en el caso del software del que estoy hablando, no lo está. Programarlo para recuperar los valores definitivamente sería una posible solución, pero implicaría codificar una ruta que debería cambiarse dependiendo de si está en el servidor de prueba o en vivo, y tener tales variaciones requeriría diferentes ramas para cada uno. que el método que propongo (filtros) evitaría.

    – Tostada de coma

    28 de agosto de 2014 a las 23:16


  • Tenga en cuenta que eliminé el carácter “<" del sed línea porque estaba causando el error, “$1: redirección ambigua”. Habiendo quitado eso, ahora es feliz. También agregué una nota sobre cómo agregar esto a un repositorio.

    – Tostada de coma

    28 de agosto de 2014 a las 23:21

¿Ha sido útil esta solución?

Esta web utiliza cookies propias y de terceros para su correcto funcionamiento y para fines analíticos y para mostrarte publicidad relacionada con sus preferencias en base a un perfil elaborado a partir de tus hábitos de navegación. Al hacer clic en el botón Aceptar, acepta el uso de estas tecnologías y el procesamiento de tus datos para estos propósitos. Configurar y más información
Privacidad