Strumenti per sviluppatori · SHA calcolatore hash
Indirizzamento dei contenuti: come Git, Docker e npm utilizzano i digest SHA come nomi
· Sfondo
sha-256 finestra mobile crittografia flusso di lavoro dello sviluppatore
I commit Git, i digest delle immagini del contenitore e le stringhe di integrità del file di lock sono tutti la stessa idea: denominare i dati in base al loro hash. Questo post spiega l'indirizzamento dei contenuti e i vantaggi che ogni ecosistema ne trae.
sha256: nella tua finestra mobile pull: cos'è quella stringa e perché non cambia mai per la stessa immagine
I sistemi di controllo della versione, i runtime dei contenitori e i gestori di pacchetti utilizzano tutti la stessa idea di denominazione: un file o una raccolta di byte viene denominata dal suo digest SHA. In Git, l'identificatore del carattere 40 SHA-1 di un commit (o il carattere 64 SHA-256 nei repository moderni) viene calcolato dal contenuto del commit: l'albero, l'autore, il timestamp e il messaggio. Cambia un singolo byte e SHA cambia. In Docker, ogni digest di livello è un hash SHA-256 dei contenuti del livello e il digest dell'immagine viene calcolato dal manifest. In npm e altri gestori di pacchetti, i campi di integrità memorizzano SHA-512 digest di tarball per verificare i download. L'indirizzamento del contenuto significa che il nome dipende solo dai byte, non da un database centrale o da un timestamp.
Il vantaggio è l’immutabilità all’interno di ciascun sistema. Un commit git SHA-256:abc... farà sempre riferimento allo stesso albero e messaggio perché l'hash determina l'identità. Se qualcuno afferma di avere un commit diverso con lo stesso SHA, sta affermando che gli stessi byte producono due hash diversi, il che interrompe la crittografia. La deduplicazione diventa automatica: due file con byte identici producono lo stesso digest, quindi i sistemi di storage possono archiviare i byte una volta e farvi riferimento due volte. Il controllo dell'integrità diventa semplice come ricalcolare il digest e confrontarlo: se i byte sono stati modificati in transito o a riposo, il digest non corrisponde più.
Denominare i dati in base al relativo hash: l'idea dell'indirizzamento del contenuto e il motivo per cui rende gratuite la deduplicazione e l'integrità
Git memorizza oggetti (commit, alberi, BLOB e tag) con chiave tramite il loro digest SHA. Il comando `git cat-file` accetta un ID oggetto e recupera i byte. L'archivio oggetti è indirizzato al contenuto: si richiede per digest, non per posizione o per nome. Quando cloni un repository, git verifica ogni oggetto ricalcolando il suo digest e confrontandolo con il digest impacchettato nel trasferimento. Il passaggio da SHA-1 a SHA-256 è graduale; i repository possono supportare entrambi per compatibilità. Il formato su disco memorizza il tipo di oggetto, la dimensione e i byte compressi. Il digest viene calcolato sulla forma canonica non compressa.
I repository Git moderni possono utilizzare SHA-256 e la transizione è in corso perché le collisioni di SHA-1 sono ora pratiche (dimostrate in 2017 e perfezionate in 2020). Un commit in un repository che utilizza SHA-256 ha un identificatore esadecimale di 64 caratteri invece di 40. Il comando `git hash-object` calcola il SHA di un blob (contenuto del file) senza memorizzarlo; `git commit-tree` calcola il SHA di una struttura ad albero e di un messaggio. Entrambe le operazioni sono deterministiche: gli stessi byte producono sempre lo stesso digest. Questo è il modo in cui GitHub e altri forge possono visualizzare gli SHA di commit in modo coerente: calcolano lo stesso digest calcolato dal clone dell'autore.
Git utilizza oggetti indirizzati al contenuto e questo strumento può riprodurre riassunti di testo; i dettagli della migrazione richiedono origini specifiche di Git
Le immagini Docker sono costruite in livelli, dove ogni livello è un delta del filesystem (modifiche rispetto al livello precedente). La specifica immagine OCI definisce come calcolare il digest di un livello e il digest del manifest dell'immagine. Il digest del livello è il SHA-256 del file tar compresso contenente i file del livello. Il manifest è un documento JSON che elenca i livelli, i relativi digest e metadati. Il digest dell'immagine è il SHA-256 del manifest JSON stesso. Quando estrai un'immagine utilizzando un tag come `latest`, il registro cerca il tag e restituisce il digest del manifest. Puoi quindi eseguire direttamente il pull by digest, assicurandoti di ottenere esattamente gli stessi byte, tutti i livelli e i metadati, ogni volta.
Il comando `docker inspect` su un'immagine locale mostra il suo digest. L'esecuzione della stessa immagine dallo stesso tag su due macchine produce lo stesso digest se il registro conserva ancora quel tag che punta allo stesso manifest. L'indirizzamento del contenuto rende controllabili le catene di fornitura delle immagini: una pipeline CI/CD può verificare che l'immagine distribuita corrisponda al digest nel registro di compilazione e uno scanner di sicurezza può segnalare tutte le immagini note per avere una vulnerabilità specifica tramite il loro digest anziché tramite tag, che può essere spostato.
Contenitori: manifest OCI e digest di livelli e perché un tag può spostarsi ma un digest no
I gestori di pacchetti utilizzano i digest per verificare i download contro manomissioni o corruzione. In npm, il file `package-lock.json` include un campo `integrity` per ogni dipendenza, contenente un hash (solitamente SHA-512) e la codifica (solitamente base64). Quando npm scarica un tarball, ricalcola l'hash e lo confronta. Se gli hash non corrispondono, l'installazione non riesce. Go utilizza un file `go.sum` con struttura simile: percorso del modulo, versione e SHA-256 dell'origine del modulo. Cargo utilizza i checksum in `Cargo.lock`. Il principio è identico: il digest viene calcolato una volta quando la dipendenza viene risolta per la prima volta e controllato ad ogni installazione successiva.
Il controllo dell'integrità non richiede il caricamento del pacchetto presso un'autorità di firma o la memorizzazione delle firme separatamente. Il digest È il controllo di integrità. Per la massima sicurezza, i progetti utilizzano `go.sum` che è firmato dal sistema di trasparenza del progetto Go, o l'integrità npm combinata con altre verifiche, ma il caso base è semplice: l'editore calcola il digest una volta, lo registra nel file di blocco e gli strumenti sul lato consumatore verificano che i byte scaricati corrispondano.
Le codifiche dell'integrità del pacchetto variano; qui vengono affermati solo gli output SHA supportati da questa calcolatrice
Gli stessi byte attraverso lo stesso algoritmo producono sempre lo stesso digest, indipendentemente dalla provenienza dei byte. La build locale di un commit da parte di uno sviluppatore produce lo stesso SHA-256 di un sistema CI/CD che estrae la stessa revisione dallo stesso repository. Questa riproducibilità è il motivo per cui l'indirizzamento del contenuto funziona: puoi verificare un artefatto senza fidarti del meccanismo di consegna. Il digest diventa un impegno crittografico: cambiare anche un solo byte lo invalida.
La distribuzione del digest separatamente (prima della distribuzione dell'artefatto) protegge dalle modifiche in corso. Una pagina Web pubblicata prima del rilascio può visualizzare "expect SHA-256:abc..." e quindi gli utenti possono verificare i download rispetto ad esso. Un commit git pubblicato in un repository pubblico è un impegno nei confronti dei byte; il digest lo dimostra.
Esempio funzionante: seguire un blob dai byte da digest al nome utilizzato da uno strumento
Sistemi diversi codificano i loro digest in modo diverso. Git utilizza il formato esadecimale minuscolo per impostazione predefinita (caratteri esadecimali 40 o 64). Docker utilizza il formato `sha256:` seguito da esadecimale. npm e Go utilizzano base64 nei campi di integrità. I byte sono gli stessi; differisce solo la rappresentazione. Un digest SHA-256 su "abc" è sempre lo stesso 256 bits, ma potresti vederlo come una stringa esadecimale di 64 caratteri, una stringa base64 di 44 caratteri o un'etichetta come `sha256:` seguita da uno dei due. La conversione tra codifiche è senza perdite; il digest ha lo stesso valore in ogni rappresentazione.
Comprendere la codifica è importante quando si confrontano i digest tra gli strumenti. Se Git stampa un digest esadecimale e uno strumento mostra base64, devi convertire una rappresentazione nell'altra per verificare che corrispondano. Il calcolatore hash SHA di ToolAcre visualizza sia esadecimale che base64 per ogni digest, facilitando la conversione o il riferimento incrociato con altri sistemi.
Ciò che questo non copre: le codifiche specifiche utilizzate da ciascuno strumento (hex rispetto a base64), trattate in un post separato
L'indirizzamento del contenuto non è specifico della crittografia, sebbene gli hash crittografici la rendano sicura. Un checksum CRC32 indirizza anche i dati dei contenuti, ma le collisioni CRC32 sono comuni e le collisioni possono essere prodotte; questo repository non contrassegna SHA-256 come danneggiato, mentre CRC32 non viene offerto come primitiva di integrità contraddittoria. La scelta dell'algoritmo hash è importante per la sicurezza: SHA-256 è lo standard moderno per i sistemi che necessitano di protezione dell'integrità contro gli avversari. SHA-1 è solo legacy (Git e altri stanno migrando). La scelta dell'algoritmo giusto è una decisione separata dalla scelta dell'indirizzamento del contenuto come schema di denominazione.
L'indirizzamento dei contenuti combinato con gli hash crittografici è il fondamento dell'integrità della catena di fornitura nel software moderno. Ogni pacchetto che installi, ogni contenitore che esegui e ogni commit che estrai può essere verificato come corrispondente ai byte previsti dall'editore originale, senza fare affidamento sul trasferimento sicuro (sebbene il trasferimento sicuro sia comunque una buona pratica).
Conclusione: l'hash è l'identità: il calcolatore di hash ToolAcre SHA ti consente di calcolare gli stessi digest su cui fanno affidamento questi sistemi
L'indirizzamento del contenuto è indipendente dalla codifica, dal luogo di archiviazione o dal meccanismo di trasferimento. Gli stessi byte producono lo stesso digest se archiviato localmente, in un CDN, in un registro o trasmesso su HTTP o protetto HTTPS. Il digest è un impegno crittografico nei byte e la sua verifica richiede solo i byte e l'algoritmo, non alcun servizio esterno. Questo è il motivo per cui l'indirizzamento del contenuto consente la verifica offline: puoi scaricare un file su un canale non attendibile, controllare il digest e sapere se i byte sono autentici.
Il calcolatore hash ToolAcre SHA ti consente di calcolare gli stessi digest su cui fanno affidamento questi sistemi. Incolla una stringa o guarda un file, esegui la calcolatrice e visualizza i digest SHA-256, SHA-384 e SHA-512 che Docker, Git, npm e altri strumenti utilizzano internamente. Confronta il tuo digest calcolato con quello della fonte originale per verificare che i byte non siano stati modificati. La calcolatrice esegue l'hashing del testo UTF-8 che incolli; non esegue l'hashing di file o materiale della chiave, quindi il confine tra ciò che può essere sottoposto ad hashing (input di testo) e ciò che non può (file binari, chiavi crittografiche nelle loro forme codificate) è chiaro e documentato.