È sicuro archiviare le password di firma APK nel repository git privato?

1. Non proprio, no. Come ha detto nerd, è molto difficile rimuoverlo dalla cronologia git se si desidera condividerlo. Git non è nemmeno pensato per contenere questo tipo di informazioni.
2. Non molto. La password crittografa solo la chiave, quindi senza la chiave crittografata, non possono realmente fare nulla.
3. Molto. Possono creare una versione della tua app con malware al suo interno e passarla come tua. Tuttavia, senza accesso al tuo account appstore, potrebbero non essere in grado di pubblicarlo direttamente. Ciò consente ancora loro di distribuirlo in altri modi, ad es. attraverso diversi app store o utilizzando il web. Se ottengono l'accesso al tuo account dell'app, possono pubblicare la versione del malware come aggiornamento e gli utenti non avrebbero modo di saperlo.
4. Sì e no. Se usi build manuali, puoi semplicemente aggiungere il file in gitignore e distribuirlo in altri modi. Se utilizzi build autonome, la maggior parte dei siti git supporta la funzionalità speciale per la memorizzazione dei segreti .

Perché no?

È tutta una questione di rischi. Il mio principale argomento contro è che se si desidera condividere quel repository con qualcuno che non dovrebbe avere la password, è davvero difficile rimuovere la password dalla cronologia git. È necessario riscrivere tutta la cronologia fino a quel momento. Quindi dovresti riscrivere tutti i commit o squash per perdere la cronologia che conteneva la password. E probabilmente non ti ricorderai di farlo, quindi è più sicuro solo lasciarli fuori.

Evita di memorizzare segreti

Per evitare di memorizzare segreti in git, di solito aggiungo il file segreto a .gitignore. Poiché qualcuno potrebbe aver bisogno di sapere cosa c'era nel file ora mancante, lasciare qualcosa come un file gradle.properties.example , con i campi redatti come "CHANGEME" o qualcosa del genere, quindi chiunque usi il file saprà come creare gradle.properties .

Se possibile, sostituire le variabili di ambiente, in modo che non sia necessario utilizzare un file .example. Personalmente raccomando uno strumento come direnv che consente di creare un file .envrc ignorato git, che può essere usato per impostare variabili d'ambiente su un base del progetto. Carica automaticamente le variabili di ambiente dal terminale quando si accede alla directory. Tuttavia, questo non sempre funziona bene con gli strumenti grafici, dal momento che le loro variabili di ambiente saranno prese dall'ambiente da cui sono state lanciate.

Alcuni IDE grafici supportano un concetto come "target" o "spazi di lavoro", che comprende che alcune opzioni di configurazione sono configurate in file che sono registrati al controllo del codice sorgente, mentre altri sono specifici dei file sul tuo computer.

Qual è il rischio?

Se qualcuno ha ricevuto la chiave di firma e la password, potrebbero firmare una copia dannosa della tua applicazione.

Se sono riusciti a inviare questa copia all'app store, i tuoi utenti potrebbero automaticamente ricevere la copia dannosa, senza alcun avviso che è stata modificata. Il loro dispositivo si fiderebbe di esso, perché è stato firmato dalla tua chiave.

Anche senza l'invio di un app store, potrebbero firmare una copia dell'applicazione e caricarla lateralmente su un dispositivo su cui era già installata l'app, che si fidava ancora perché era firmata dalla stessa chiave.