Quando posso eseguire il commit di una chiave privata per il controllo del codice sorgente?

In generale il codice di mixaggio e la configurazione segreta (password, chiavi, ecc.) nello stesso ripostiglio è una cattiva idea perché in genere molte più persone hanno bisogno (o almeno trarranno vantaggio) dall'accesso al codice di quello che è necessario accedere a qualsiasi dato segreto . Anche il flusso di lavoro comune con i sistemi VCS è creare molte copie.

Questo non significa che non puoi mettere la configurazione segreta in un VCS ma dovrebbe essere un repository separato dal tuo codice e l'accesso ad esso dovrebbe essere strettamente controllato.

Quando la chiave privata non è altro che un dispositivo di prova utilizzato per testare alcuni processi che richiedono una chiave privata e in cui la chiave privata non viene effettivamente utilizzata per proteggere alcun sistema.

In alcuni casi può essere appropriato eseguire il commit di una chiave crittografata . Ad esempio se il repository è pubblico / open source ma un sistema di integrazione continua richiede l'accesso a quel file - Travis CI supporta questo .

Altrimenti non dovresti commettere chiavi private.

Penso che quello che devi chiederti è:

If the key gets compromised, can I detect it?

e

How does the revoking process affect other people?

Ad esempio: cosa succede se il repository di controllo del codice sorgente interno viene prelevato al di fuori del perimetro aziendale, ad es. tramite il laptop di uno sviluppatore? Cosa succede se questo laptop viene rubato? Che cosa succede se si tratta di un dipendente insoddisfatto che ne fa una copia e la tiene sul proprio laptop personale?

In altre parole, la chiave può essere utilizzata per accedere a una risorsa pubblica e, in caso affermativo, qual è il danno?

Se le tue pratiche di sviluppo richiedono la condivisione di una chiave privata, allora non è una chiave privata per definizione. Potresti voler pensare al motivo per cui ciò sta accadendo e se devi considerare il token di accesso per utente (ad esempio oAuth, una chiave API) o altre soluzioni.

Poiché questa risposta non è stata ancora data, sembra che io debba:

Mai mai. Davvero mai .

Come già sottolineato, per definizione una chiave privata dovrebbe essere tenuta segreta. Ma il controllo del codice sorgente è fatto per condividere e rendere disponibili le informazioni (forse per un pubblico limitato, ma comunque).

Il motivo per cui potresti volerlo fare è solo perché non hai i processi che devi avere in atto. Anche se potresti voler utilizzare quella chiave per alcuni sistemi di test che verranno cancellati dopo ogni esecuzione di test, probabilmente non applichi le tue intenzioni. Le intenzioni decadono nel tempo e ad un certo punto nel tempo la chiave verrà utilizzata in produzione.

Quando si eseguono analisi di crittografia per cose come attacchi Man in the Middle, è tipico definire le parti in base alla loro conoscenza. Quindi tecniche per permettere ad Alice di parlare con Bob e permettere a Bob di credere che il messaggio di Alice definisca Alice come "qualcuno che sa tutto ciò che è importante sapere Alice".

Inserendo la chiave privata nel repository, è ora necessario eseguire tutte le analisi di sicurezza in cui la chiave privata è ora una chiave privata per "chiunque possa scaricare il repository o ottenere una copia in altro modo".

Se quel livello di sicurezza è sufficiente per la tua chiave privata, allora puoi metterlo nel repository. Altrimenti, metterlo nel repository invaliderà qualsiasi prova di sicurezza che dipenda dalla diffusione della chiave privata più stretta di quella.