Perché la chiave del tuo sito non sta nel codice

Se la chiave del tuo sito sta nel codice, la domanda è se quella chiave cambia tra il computer su cui scrivi e la macchina che serve il sito. Il 3 novembre 2026 ho letto la pagina sulla configurazione aggiornata nel 2017, due edizioni della norma POSIX sulle variabili d'ambiente, e il manuale di gitignore. Non dicono la stessa cosa. Non ho misurato un sito e non ho aperto un repository.

La configurazione, aggiornata nel 2017

La pagina The Twelve-Factor App, fattore Config, scrive Last updated 2017. In fondo il copyright è 2026, Salesforce. Nella risposta letta il 3 novembre 2026 non c'è last-modified. Le due date non coincidono. Non le unisco. Definisce la configurazione come tutto ciò che è probabile cambi tra i deploy: staging, produzione, ambienti di sviluppo, e così via. Nell'elenco mette i riferimenti a risorse come la base dati, Memcached e gli altri servizi di appoggio. Poi le credenziali verso servizi esterni: gli esempi della pagina sono Amazon S3 e Twitter. Poi i valori che cambiano per ogni deploy, come il nome canonico di quel deploy.

Scrive che a volte la configurazione sta come costante nel codice. Per quella pagina è una violazione, perché chiede una separazione stretta tra configurazione e codice. La configurazione varia in modo sostanziale tra i deploy. Il codice no. La prova che propone è se il codice potrebbe essere reso pubblico in qualsiasi momento, senza compromettere alcuna credenziale. È la prova di quella pagina. Non è un incidente che ho visto.

La stessa pagina dice che questa definizione non include la configurazione interna dell'applicazione, come le rotte in un file di Rails o il modo in cui i moduli sono collegati in Spring. Quel tipo non varia tra i deploy, e per la pagina sta bene nel codice. Non lo metto nello stesso mucchio delle credenziali.

Un altro modo, scrive, sono i file di configurazione che non entrano nel controllo di revisione. L'esempio è il file della base dati di Rails. Lo chiama un grande miglioramento rispetto alle costanti finite nel repository, e poi ne elenca i punti deboli: è facile commettere per sbaglio un file di configurazione; i file tendono a spargersi in posti e formati diversi, e diventa difficile vedere tutta la configurazione in un solo posto; quei formati tendono a essere legati a un linguaggio o a un framework.

La pagina dice che l'applicazione a dodici fattori tiene la configurazione nelle variabili d'ambiente. Sono facili da cambiare tra i deploy senza cambiare codice. A differenza dei file di configurazione, c'è poca probabilità che finiscano per sbaglio nel repository. A differenza dei file di configurazione propri o di altri meccanismi, come le proprietà di sistema di Java, sono uno standard indipendente dal linguaggio e dal sistema. Poca probabilità non è una garanzia. Non la trasformo in una.

Poi parla dei gruppi. A volte le applicazioni raggruppano la configurazione in nomi di ambienti, come development, test e production nell'esempio di Rails. La pagina dice che questo metodo non scala in modo pulito: più deploy nascono, più nomi servono, come staging o qa, e poi ambienti personali. Il risultato che descrive è un'esplosione di combinazioni che rende fragili i deploy. Nell'applicazione a dodici fattori le variabili sono controlli granulari, ognuno indipendente dagli altri. Non vanno raggruppate come ambienti. Si gestiscono a parte, per ogni deploy. Il gruppo di nomi e la variabile singola restano due frasi. Non le unisco.

Due edizioni della norma

Ho letto il capitolo 8.1 in due edizioni. La pagina dell'edizione 2018 dice che esiste un'edizione più nuova, e rimanda a un altro indirizzo. Quell'indirizzo, letto lo stesso giorno, è l'edizione 8, IEEE Std 1003.1-2024, copyright 2001-2024. L'edizione che rimanda è la Issue 7, 2018 edition, IEEE Std 1003.1-2017, revisione della IEEE Std 1003.1-2008, copyright 2001-2018. Nessuna delle due risposte aveva last-modified. Non ho aperto le pagine delle singole funzioni.

Sul valore non usano la stessa frase. L'edizione 2018 dice che il valore di una variabile d'ambiente è una stringa di caratteri. L'edizione 2024 dice che il valore è una sequenza arbitraria di byte, salvo il byte nullo. Non le unisco.

Il resto, nelle frasi che ho confrontato, resta allineato e lo riporto come frase comune. Per un programma in C, quando un processo comincia è disponibile un array di stringhe chiamato ambiente, puntato dalla variabile esterna environ. La dichiarazione non la incollo. Le stringhe hanno la forma nome uguale valore. Il nome non deve contenere il carattere uguale: l'edizione 2024 lo dice come byte che hanno il valore codificato di quel carattere. Non c'è un significato nell'ordine delle stringhe. Se più di una stringa ha lo stesso nome, le conseguenze sono indefinite. I nomi usati dalle utilità sono solo lettere maiuscole, cifre e trattino basso, e non cominciano con una cifra. Altri caratteri possono essere ammessi da un'implementazione, e le applicazioni devono tollerarli. L'edizione 2024 aggiunge, in quella frase, anche sequenze di byte che non formano caratteri validi. Maiuscole e minuscole restano distinte e non si piegano l'una sull'altra. Lo spazio dei nomi con lettere minuscole è riservato alle applicazioni. Una nota sconsiglia i nomi che cominciano con una cifra, perché altre applicazioni possono avere difficoltà. I valori non sono ristretti, salvo che si considerano terminati da un byte nullo e che lo spazio totale per l'ambiente e per gli argomenti del processo è limitato a ARG_MAX byte. La pagina nomina delle funzioni che possono mettere altre coppie nell'ambiente. Quelle pagine non le ho aperte. Non descrivo come si impostano.

Queste edizioni non parlano di credenziali, né di repository, né della prova del 2017. Non le uso per dire che una variabile è un posto sicuro. Dicono che cosa è il valore, e che due stringhe con lo stesso nome hanno conseguenze indefinite.

Il file che Git ignora

Il manuale gitignore, letto il 3 novembre 2026, dice nella pagina che è aggiornato nella versione 2.55.0. Nell'elenco delle versioni, 2.55.0 è datato 29 giugno 2026, e 2.56.0 non ha cambiamenti. Last-modified della risposta: 2 novembre 2026 alle 06:50:40 GMT. Il 29 giugno e il 2 novembre non coincidono. Non li unisco. Il manuale definisce gitignore come il file che specifica i file intenzionalmente non tracciati che Git dovrebbe ignorare. I file già tracciati non sono toccati. Ogni riga è un modello. I modelli non li copio: gli esempi del manuale usano un segno che non incollo.

Per decidere se ignorare un percorso, Git controlla di solito più fonti, dalla precedenza più alta alla più bassa. Dentro lo stesso livello, decide l'ultimo modello che corrisponde. Le fonti, in ordine, sono: i modelli letti dalla riga di comando, per i comandi che li accettano; i modelli letti da un file gitignore nella stessa directory del percorso o in una directory genitore, fino alla cima dell'albero di lavoro, e i file più in basso sovrascrivono quelli più in alto; i modelli relativi alla posizione di quel file. Un progetto di solito include questi file nel repository, con modelli per i file generati dalla build. Poi i modelli letti da info/exclude nella directory comune di Git. Poi i modelli letti dal file indicato dalla variabile di configurazione core.excludesFile. Il valore predefinito è il file ignore sotto la configurazione XDG, e se quella variabile non c'è o è vuota si usa il file ignore sotto la configurazione nella home. Quale file usare dipende da come il modello va usato. I modelli che devono essere versionati e distribuiti con il clone, quelli che tutti vogliono ignorare, stanno nel file gitignore. I modelli specifici di un repository ma che non vanno condivisi stanno in info/exclude. I modelli che una persona vuole in ogni situazione, per esempio i file di backup o i temporanei dell'editor, stanno nel file di core.excludesFile.

Le note dicono che lo scopo è far restare non tracciati certi file che Git non traccia. Per smettere di tracciare un file che è già tracciato, le note dicono di toglierlo dall'indice con il comando che nominano, e poi di aggiungere il nome al file gitignore perché i commit successivi non lo rimettano. Non ho eseguito il comando. Le note non dicono che questo cancelli il file dalla storia già scritta. Non lo aggiungo. Git non segue i collegamenti simbolici quando legge un file gitignore nell'albero di lavoro.

Questo manuale non dice che una variabile d'ambiente sia il posto della chiave. Dice quali file restano non tracciati. La pagina del 2017, a parte, dice che un file di configurazione tenuto fuori dal controllo di revisione è un miglioramento rispetto alla costante nel codice, ed è facile commetterlo per sbaglio. Il manuale dice che un file già tracciato non è toccato dal file gitignore. Sono due limiti, di due pagine. Non li fondo in una sola ricetta.

Che cosa non rimetto

La pagina su npm ci parla di quali versioni finiscono nella build. Nomina NODE_ENV per il valore predefinito di omit, quando vale production. È una frase su quali gruppi di dipendenze si omettono. Non è una frase su dove vive una credenziale. Non riscrivo quella pagina.

La pagina su Composer nomina le variabili COMPOSER_WITH_DEPENDENCIES e COMPOSER_WITH_ALL_DEPENDENCIES come modo per fissare due opzioni del comando. Non è un posto per una chiave. Non la riscrivo.

La pagina su pip chiama ambiente il file dei requisiti, spesso un ambiente intero di installazione. Non è questo campo. Non la riscrivo.

La pagina sul lucchetto parla del transito cifrato. Il certificato è un altro oggetto. Non la riscrivo. Non riscrivo la pagina sulla compressione né quella sulla cartella chiusa.

Non ho copiato i modelli, la dichiarazione in C, né l'elenco lungo dei nomi con cui la norma sconsiglia di entrare in conflitto. Non ho inventato una chiave finita in un repository, né un incidente.

Esempio ipotetico

prova.bottega.example è un nome di scuola. Non ho aperto quel nome e non ho letto una sua variabile.

Non le assegno una chiave, un riferimento alla base dati, un nome canonico, una stringa sul computer e un'altra sul server, né un file già tracciato. Non la pubblico, perché non l'ho misurata.

Che cosa questa pagina lascia stare

Non ho misurato un sito. Non ho aperto le pagine delle funzioni che mettono una coppia nell'ambiente. Non ho eseguito Git. Non ho riscritto le pagine su npm, Composer, pip, il lucchetto, la compressione e la cartella. La copertina di questa pagina è nuova, perché la pagina è nuova.

Fonti lette il 3 novembre 2026. The Twelve-Factor App, Config, Last updated 2017, copyright 2026 in fondo alla pagina, senza last-modified nella risposta, https://12factor.net/config. POSIX Issue 7, 2018 edition, IEEE Std 1003.1-2017, capitolo 8.1, senza last-modified, https://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap08.html. POSIX Issue 8, IEEE Std 1003.1-2024, capitolo 8.1, senza last-modified, https://pubs.opengroup.org/onlinepubs/9799919799/basedefs/V1_chap08.html. Manuale gitignore, aggiornato in pagina nella 2.55.0 datata 29 giugno 2026, 2.56.0 senza cambiamenti, last-modified 2 novembre 2026 alle 06:50:40 GMT, https://git-scm.com/docs/gitignore.