¿Cómo se manejan los datos confidenciales en un repositorio público de git?

Question

¿Cómo se manejan los datos confidenciales, como las claves secretas API, sales hash cuando se guarda el código en un repositorio público de git?

Obviamente, mantener los datos confidenciales en el código lo comprometerá.

Otra solución es no codificar la información secreta en el código, sino almacenarla en un archivo independiente y cambiar el nombre del archivo. Esto tiene la desventaja de que cuando alguien saca su código por primera vez, la información secreta se perderá y no se ejecutará fuera de la caja. Esto puede explicarse escribiendo una rutina de "inicialización si falta" en el código, pero luego está dejando que el sistema git se deslice dentro de su código, lo que es IMO no es algo bueno.

Y otra solución es crear un archivo de información secreto "predeterminado", confirmarlo al comienzo del proyecto y luego usar su propia información sin comprometerla. Pero esto puede hacer que Git se queje de que tienes cambios no comprometidos cuando tiras.

Entonces, ¿cuál es la forma más común de manejar esto?

Answer 1

La mejor solución sería un git submodule privado y un repositorio público de git.

Consulte this quesiton para obtener más información; una buena cita para usted:

Cuando excluye o ignora lo que está haciendo es evitar que los archivos se agreguen a su repositorio. ninguno de los archivos de "archivos confidenciales" está incluso en el repositorio, solo en su directorio de trabajo.

Answer 2

El archivo de información secreta "predeterminado" es una buena idea, sin embargo, no hay forma de evitar las advertencias de git, incluso si ignora el archivo. Desde el github help page:

git no ignorará un archivo que ya fue seguido antes de una regla fue agregada a este archivo de ignorarlo. En tal caso, el archivo debe ser un-seguimiento, por lo general con git rm --cached filename

Por lo tanto, la adición de una "falsa" o archivo "default" y luego haciendo caso omiso de que no impedirá que las advertencias. Aunque el enfoque funcionará, será inconveniente ya que siempre tendrá que excluir manualmente el archivo confidencial de cada confirmación.

Al destrabar el archivo, se elimina de github, lo que frustra el propósito de tener el archivo en primer lugar.

Quizás la sugerencia del submódulo funcione.

Answer 3

Podría decirse que no debe codificar estas propiedades en su fuente, ya que un administrador querrá la opción de cambiarlas en un sistema determinado. Si estas propiedades están en un archivo de propiedades (por ejemplo, en su directorio personal), el problema está resuelto.

Para los usuarios que puedan tener problemas, puede verificar un archivo predeterminado que pueden copiar en su carpeta de inicio y modificar. Si los mensajes de error y README son claros sobre el tema de perder este archivo en particular, esta configuración funcionará bastante bien.

Answer 4

intenta utilizar .gitattributes de camino con filtro configurado el cifrado/descifrado:

*secure.yml filter=crypt 

Y en el .git/config añadir la configuración de filtro de la cripta:

[filter "crypt"] 
    clean = openssl enc ... 
    smudge = openssl enc -d ... 
    required 

Answer 5

Si alguien necesita para su Proyecto de Android, hay la manera más simple que encuentro:

paso 1: crear: res/values ​​/ secrets.xml con:

<!-- Inside of `res/values/secrets.xml` --> 
<?xml version="1.0" encoding="utf-8"?> 
<resources> 
    <string name="parse_application_id">xxxxxx</string> 
    <string name="parse_client_secret">yyyyyy</string> 
    <string name="google_maps_api_key">zzzzzz</string> 
</resources> 

paso 2: utilizar en el código XML o archivo

getString(R.string.parse_application_id), 
getString(R.string.parse_client_secret) 

o

<meta-data 
    android:name="com.google.android.maps.v2.API_KEY" 
    android:value="@string/google_maps_api_key"/> 

Paso 3: añadir esta línea en el archivo .gitignore

**/*/res/values/secrets.xml 

aquí es el completo article