¿Es seguro almacenar las contraseñas de firma de APK en el repositorio privado de git?

1. En realidad no, no. Como dijo nbering, es muy difícil eliminarlo del historial de git si alguna vez quieres compartirlo. Git tampoco está realmente destinado a mantener este tipo de información.
2. No mucho. La contraseña solo cifra la clave, por lo tanto, sin la clave cifrada, no pueden hacer nada.
3. mucho. Pueden crear una versión de su aplicación con malware en su interior y pasarla como suya. Sin embargo, sin acceso a su cuenta de appstore, es posible que no puedan publicarla directamente. Esto todavía les permite distribuirlo de otras maneras, por ejemplo. A través de diferentes appstores o utilizando la web. Si obtienen acceso a su cuenta de appstore, pueden publicar su versión de malware como una actualización y los usuarios no tendrían forma de saberlo.
4. Sí y no. Si usa compilaciones manuales, puede agregar el archivo en gitignore y distribuirlo de otras maneras. Si utiliza compilaciones autónomas, la mayoría de los sitios de git admiten funcionalidad especial para almacenar secretos .

¿Por qué no?

Todo es una cuestión de riesgo. Mi principal argumento en contra es que si alguna vez quieres compartir ese repositorio con alguien que no debería tener la contraseña, es realmente difícil eliminar la contraseña del historial de git. Necesitas reescribir todo el historial a ese punto. Así que tendrías que volver a escribir todas las confirmaciones, o aplastar para perder el historial que contenía la contraseña. Y probablemente no recuerdes hacer eso, así que es más seguro dejarlos fuera.

Evita cometer secretos

Para evitar almacenar secretos en git, generalmente agrego el archivo secreto a .gitignore. Como es posible que alguien necesite saber qué había en el archivo que falta ahora, deje algo como un archivo gradle.properties.example , con los campos redactados como "CHANGEME" o algo así, para que cualquiera que use el archivo sepa cómo crear gradle.properties .

Si es posible, sustitúyalo de las variables de entorno, para que no tenga que usar un archivo .example. Personalmente recomiendo una herramienta como direnv que le permite crear un archivo .envrc ignorado por git, que se puede usar para establecer variables de entorno en un momento determinado. base del proyecto. Automáticamente carga las variables de entorno desde el terminal cuando ingresa al directorio. Sin embargo, esto no siempre funciona bien con herramientas gráficas, ya que sus variables de entorno se tomarán del entorno desde el que se lanzaron.

Algunas IDE gráficas admiten un concepto como "objetivos" o "áreas de trabajo", que entiende que algunas opciones de configuración están configuradas en archivos que están registrados en el control de origen, y otras son específicas de los archivos en su computadora.

¿Cuál es el riesgo?

Si alguien supo de tu clave de firma y de la contraseña, podría firmar una copia maliciosa de tu aplicación.

Si lograron enviar esta copia a la tienda de aplicaciones, sus usuarios pueden recibir automáticamente la copia maliciosa, sin previo aviso de que se haya cambiado. Su dispositivo confiaría en ello, porque estaba firmado por su clave.

Incluso sin el envío de una tienda de aplicaciones, es posible que puedan firmar una copia de la aplicación y cargarla en un dispositivo donde la aplicación ya estaba instalada, en la que aún confiarían porque estaba firmada por la misma clave.