OSCL-LXR linux-6.0.1/​Documentation/​translations/​it_IT/​process/​maintainer-pgp-guide.rst	Source navigation Diff markup Identifier search General search
	Version: linux-6.0.1 spark-3.0.0 hadoop-3.2.0-src hadoop-3.3.0-src spark-2.4.7 linux-4.15.13 hadoop-2.7.4-src Revert   Change

 .. include:: ../disclaimer-ita.rst
 
 :Original: :ref:`Documentation/process/maintainer-pgp-guide.rst <pgpguide>`
 :Translator: Alessia Mantegazza <amantegazza@vaga.pv.it>
 
 .. _it_pgpguide:
 
 =========================================
 La guida a PGP per manutentori del kernel
 =========================================
 
 :Author: Konstantin Ryabitsev <konstantin@linuxfoundation.org>
 
 Questo documento è destinato agli sviluppatori del kernel Linux, in particolar
 modo ai manutentori. Contiene degli approfondimenti riguardo informazioni che
 sono state affrontate in maniera più generale nella sezione
 "`Protecting Code Integrity`_" pubblicata dalla Linux Foundation.
 Per approfondire alcuni argomenti trattati in questo documento è consigliato
 leggere il documento sopraindicato
 
 .. _`Protecting Code Integrity`: https://github.com/lfit/itpol/blob/master/protecting-code-integrity.md
 
 Il ruolo di PGP nello sviluppo del kernel Linux
 ===============================================
 
 PGP aiuta ad assicurare l'integrità del codice prodotto dalla comunità
 di sviluppo del kernel e, in secondo luogo, stabilisce canali di comunicazione
 affidabili tra sviluppatori attraverso lo scambio di email firmate con PGP.
 
 Il codice sorgente del kernel Linux è disponibile principalmente in due
 formati:
 
 - repositori distribuiti di sorgenti (git)
 - rilasci periodici di istantanee (archivi tar)
 
 Sia i repositori git che gli archivi tar portano le firme PGP degli
 sviluppatori che hanno creato i rilasci ufficiali del kernel. Queste firme
 offrono una garanzia crittografica che le versioni scaricabili rese disponibili
 via kernel.org, o altri portali, siano identiche a quelle che gli sviluppatori
 hanno sul loro posto di lavoro. A tal scopo:
 
 - i repositori git forniscono firme PGP per ogni tag
 - gli archivi tar hanno firme separate per ogni archivio
 
 .. _it_devs_not_infra:
 
 Fidatevi degli sviluppatori e non dell'infrastruttura
 -----------------------------------------------------
 
 Fin dal 2011, quando i sistemi di kernel.org furono compromessi, il principio
 generale del progetto Kernel Archives è stato quello di assumere che qualsiasi
 parte dell'infrastruttura possa essere compromessa in ogni momento. Per questa
 ragione, gli amministratori hanno intrapreso deliberatemene dei passi per
 enfatizzare che la fiducia debba risiedere sempre negli sviluppatori e mai nel
 codice che gestisce l'infrastruttura, indipendentemente da quali che siano le
 pratiche di sicurezza messe in atto.
 
 Il principio sopra indicato è la ragione per la quale è necessaria questa
 guida. Vogliamo essere sicuri che il riporre la fiducia negli sviluppatori
 non sia fatto semplicemente per incolpare qualcun'altro per future falle di
 sicurezza. L'obiettivo è quello di fornire una serie di linee guida che gli
 sviluppatori possano seguire per creare un ambiente di lavoro sicuro e
 salvaguardare le chiavi PGP usate nello stabilire l'integrità del kernel Linux
 stesso.
 
 .. _it_pgp_tools:
 
 Strumenti PGP
 =============
 
 Usare GnuPG v2
 --------------
 
 La vostra distribuzione potrebbe avere già installato GnuPG, dovete solo
 verificare che stia utilizzando la versione 2.x e non la serie 1.4 --
 molte distribuzioni forniscono entrambe, di base il comando ''gpg''
 invoca GnuPG v.1. Per controllate usate::
 
     $ gpg --version | head -n1
 
 Se visualizzate ``gpg (GnuPG) 1.4.x``, allora state usando GnuPG v.1.
 Provate il comando ``gpg2`` (se non lo avete, potreste aver bisogno
 di installare il pacchetto gnupg2)::
 
     $ gpg2 --version | head -n1
 
 Se visualizzate  ``gpg (GnuPG) 2.x.x``, allora siete pronti a partire.
 Questa guida assume che abbiate la versione 2.2.(o successiva) di GnuPG.
 Se state usando la versione 2.0, alcuni dei comandi indicati qui non
 funzioneranno, in questo caso considerate un aggiornamento all'ultima versione,
 la 2.2. Versioni di gnupg-2.1.11 e successive dovrebbero essere compatibili
 per gli obiettivi di questa guida.
 
 Se avete entrambi i comandi: ``gpg`` e ``gpg2``, assicuratevi di utilizzare
 sempre la versione V2, e non quella vecchia. Per evitare errori potreste creare
 un alias::
 
     $ alias gpg=gpg2
 
 Potete mettere questa opzione nel vostro  ``.bashrc`` in modo da essere sicuri.
 
 Configurare le opzioni di gpg-agent
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
 L'agente GnuPG è uno strumento di aiuto che partirà automaticamente ogni volta
 che userete il comando ``gpg`` e funzionerà in background con l'obiettivo di
 individuare la passphrase. Ci sono due opzioni che dovreste conoscere
 per personalizzare la scadenza della passphrase nella cache:
 
 - ``default-cache-ttl`` (secondi): Se usate ancora la stessa chiave prima
   che il time-to-live termini, il conto alla rovescia si resetterà per un
   altro periodo. Di base è di 600 (10 minuti).
 
 - ``max-cache-ttl`` (secondi): indipendentemente da quanto sia recente l'ultimo
   uso della chiave da quando avete inserito la passphrase, se il massimo
   time-to-live è scaduto, dovrete reinserire nuovamente la passphrase.
   Di base è di 30 minuti.
 
 Se ritenete entrambe questi valori di base troppo corti (o troppo lunghi),
 potete creare il vostro file ``~/.gnupg/gpg-agent.conf`` ed impostare i vostri
 valori::
 
     # set to 30 minutes for regular ttl, and 2 hours for max ttl
     default-cache-ttl 1800
     max-cache-ttl 7200
 
 .. note::
 
     Non è più necessario far partire l'agente gpg manualmente all'inizio della
     vostra sessione. Dovreste controllare i file rc per rimuovere tutto ciò che
     riguarda vecchie le versioni di GnuPG, poiché potrebbero non svolgere più
     bene il loro compito.
 
 Impostare un *refresh* con cronjob
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
 Potreste aver bisogno di rinfrescare regolarmente il vostro portachiavi in
 modo aggiornare le chiavi pubbliche di altre persone, lavoro che è svolto
 al meglio con un cronjob giornaliero::
 
     @daily /usr/bin/gpg2 --refresh >/dev/null 2>&1
 
 Controllate il percorso assoluto del vostro comando ``gpg`` o ``gpg2`` e usate
 il comando ``gpg2`` se per voi ``gpg`` corrisponde alla versione GnuPG v.1.
 
 .. _it_master_key:
 
 Proteggere la vostra chiave PGP primaria
 ========================================
 
 Questa guida parte dal presupposto che abbiate già una chiave PGP che usate
 per lo sviluppo del kernel Linux. Se non ne avete ancora una, date uno sguardo
 al documento "`Protecting Code Integrity`_" che abbiamo menzionato prima.
 
 Dovreste inoltre creare una nuova chiave se quella attuale è inferiore a 2048
 bit (RSA).
 
 Chiave principale o sottochiavi
 -------------------------------
 
 Le sottochiavi sono chiavi PGP totalmente indipendenti, e sono collegate alla
 chiave principale attraverso firme certificate. È quindi importante
 comprendere i seguenti punti:
 
 1. Non ci sono differenze tecniche tra la chiave principale e la sottochiave.
 2. In fesa di creazione, assegniamo limitazioni funzionali ad ogni chiave
    assegnando capacità specifiche.
 3. Una chiave PGP può avere 4 capacità:
 
    - **[S]** può essere usata per firmare
    - **[E]** può essere usata per criptare
    - **[A]** può essere usata per autenticare
    - **[C]** può essere usata per certificare altre chiavi
 
 4. Una singola chiave può avere più capacità
 5. Una sottochiave è completamente indipendente dalla chiave principale.
    Un messaggio criptato con la sottochiave non può essere decrittato con
    quella principale. Se perdete la vostra sottochiave privata, non può
    essere rigenerata in nessun modo da quella principale.
 
 La chiave con capacità **[C]** (certify) è identificata come la chiave
 principale perché è l'unica che può essere usata per indicare la relazione
 con altre chiavi. Solo la chiave **[C]** può essere usata per:
 
 - Aggiungere o revocare altre chiavi (sottochiavi) che hanno capacità S/E/A
 - Aggiungere, modificare o eliminare le identità (unids) associate alla chiave
 - Aggiungere o modificare la data di termine di sé stessa o di ogni sottochiave
 - Firmare le chiavi di altre persone a scopo di creare una rete di fiducia
 
 Di base, alla creazione di nuove chiavi, GnuPG genera quanto segue:
 
 - Una chiave madre che porta sia la capacità di certificazione che quella
   di firma (**[SC]**)
 - Una sottochiave separata con capacità di criptaggio (**[E]**)
 
 Se avete usato i parametri di base per generare la vostra chiave, quello
 sarà il risultato. Potete verificarlo utilizzando ``gpg --list-secret-keys``,
 per esempio::
 
     sec   rsa2048 2018-01-23 [SC] [expires: 2020-01-23]
           000000000000000000000000AAAABBBBCCCCDDDD
     uid           [ultimate] Alice Dev <adev@kernel.org>
     ssb   rsa2048 2018-01-23 [E] [expires: 2020-01-23]
 
 Qualsiasi chiave che abbia la capacità **[C]** è la vostra chiave madre,
 indipendentemente da quali altre capacità potreste averle assegnato.
 
 La lunga riga sotto la voce ``sec`` è la vostra impronta digitale --
 negli esempi che seguono, quando vedere ``[fpr]`` ci si riferisce a questa
 stringa di 40 caratteri.
 
 Assicuratevi che la vostra passphrase sia forte
 -----------------------------------------------
 
 GnuPG utilizza le passphrases per criptare la vostra chiave privata prima
 di salvarla sul disco. In questo modo, anche se il contenuto della vostra
 cartella ``.gnupg`` venisse letto o trafugato nella sia interezza, gli
 attaccanti non potrebbero comunque utilizzare le vostre chiavi private senza
 aver prima ottenuto la passphrase per decriptarle.
 
 È assolutamente essenziale che le vostre chiavi private siano protette da
 una passphrase forte. Per impostarla o cambiarla, usate::
 
     $ gpg --change-passphrase [fpr]
 
 Create una sottochiave di firma separata
 ----------------------------------------
 
 Il nostro obiettivo è di proteggere la chiave primaria spostandola su un
 dispositivo sconnesso dalla rete, dunque se avete solo una chiave combinata
 **[SC]** allora dovreste creare una sottochiave di firma separata::
 
     $ gpg --quick-add-key [fpr] ed25519 sign
 
 Ricordate di informare il keyserver del vostro cambiamento, cosicché altri
 possano ricevere la vostra nuova sottochiave::
 
     $ gpg --send-key [fpr]
 
 .. note:: Supporto ECC in GnuPG
     GnuPG 2.1 e successivi supportano pienamente *Elliptic Curve Cryptography*,
     con la possibilità di combinare sottochiavi ECC con le tradizionali chiavi
     primarie RSA. Il principale vantaggio della crittografia ECC è che è molto
     più veloce da calcolare e crea firme più piccole se confrontate byte per
     byte con le chiavi RSA a più di 2048 bit. A meno che non pensiate di
     utilizzare un dispositivo smartcard che non supporta le operazioni ECC, vi
     raccomandiamo ti creare sottochiavi di firma ECC per il vostro lavoro col
     kernel.
 
     Se per qualche ragione preferite rimanere con sottochiavi RSA, nel comando
     precedente, sostituite "ed25519" con "rsa2048". In aggiunta, se avete
     intenzione di usare un dispositivo hardware che non supporta le chiavi
     ED25519 ECC, come la Nitrokey Pro o la Yubikey, allora dovreste usare
     "nistp256" al posto di "ed25519".
 
 Copia di riserva della chiave primaria per gestire il recupero da disastro
 --------------------------------------------------------------------------
 
 Maggiori sono le firme di altri sviluppatori che vengono applicate alla vostra,
 maggiori saranno i motivi per avere una copia di riserva che non sia digitale,
 al fine di effettuare un recupero da disastro.
 
 Il modo migliore per creare una copia fisica della vostra chiave privata è
 l'uso del programma ``paperkey``. Consultate ``man paperkey`` per maggiori
 dettagli sul formato dell'output ed i suoi punti di forza rispetto ad altre
 soluzioni. Paperkey dovrebbe essere già pacchettizzato per la maggior parte
 delle distribuzioni.
 
 Eseguite il seguente comando per creare una copia fisica di riserva della
 vostra chiave privata::
 
     $ gpg --export-secret-key [fpr] | paperkey -o /tmp/key-backup.txt
 
 Stampate il file (o fate un pipe direttamente verso lpr), poi prendete
 una penna e scrivete la passphare sul margine del foglio.  **Questo è
 caldamente consigliato** perché la copia cartacea è comunque criptata con
 la passphrase, e se mai doveste cambiarla non vi ricorderete qual'era al
 momento della creazione di quella copia -- *garantito*.
 
 Mettete la copia cartacea e la passphrase scritta a mano in una busta e
 mettetela in un posto sicuro e ben protetto, preferibilmente fuori casa,
 magari in una cassetta di sicurezza in banca.
 
 .. note::
 
     Probabilmente la vostra stampante non è più quello stupido dispositivo
     connesso alla porta parallela, ma dato che il suo output è comunque
     criptato con la passphrase, eseguire la stampa in un sistema "cloud"
     moderno dovrebbe essere comunque relativamente sicuro. Un'opzione potrebbe
     essere quella di cambiare la passphrase della vostra chiave primaria
     subito dopo aver finito con paperkey.
 
 Copia di riserva di tutta la cartella GnuPG
 -------------------------------------------
 
 .. warning::
 
     **!!!Non saltate questo passo!!!**
 
 Quando avete bisogno di recuperare le vostre chiavi PGP è importante avere
 una copia di riserva pronta all'uso. Questo sta su un diverso piano di
 prontezza rispetto al recupero da disastro che abbiamo risolto con
 ``paperkey``. Vi affiderete a queste copie esterne quando dovreste usare la
 vostra chiave Certify -- ovvero quando fate modifiche alle vostre chiavi o
 firmate le chiavi di altre persone ad una conferenza o ad un gruppo d'incontro.
 
 Incominciate con una piccola chiavetta di memoria USB (preferibilmente due)
 che userete per le copie di riserva. Dovrete criptarle usando LUKS -- fate
 riferimento alla documentazione della vostra distribuzione per capire come
 fare.
 
 Per la passphrase di criptazione, potete usare la stessa della vostra chiave
 primaria.
 
 Una volta che il processo di criptazione è finito, reinserite il disco USB ed
 assicurativi che venga montato correttamente. Copiate interamente la cartella
 ``.gnugp`` nel disco criptato::
 
     $ cp -a ~/.gnupg /media/disk/foo/gnupg-backup
 
 Ora dovreste verificare che tutto continui a funzionare::
 
     $ gpg --homedir=/media/disk/foo/gnupg-backup --list-key [fpr]
 
 Se non vedete errori, allora dovreste avere fatto tutto con successo.
 Smontate il disco USB, etichettatelo per bene di modo da evitare di
 distruggerne il contenuto non appena vi serve una chiavetta USB a caso, ed
 infine mettetelo in un posto sicuro -- ma non troppo lontano, perché vi servirà
 di tanto in tanto per modificare le identità, aggiungere o revocare
 sottochiavi, o firmare le chiavi di altre persone.
 
 Togliete la chiave primaria dalla vostra home
 ---------------------------------------------
 
 I file che si trovano nella vostra cartella home non sono poi così ben protetti
 come potreste pensare. Potrebbero essere letti o trafugati in diversi modi:
 
 - accidentalmente quando fate una rapida copia della cartella home per
   configurare una nuova postazione
 - da un amministratore di sistema negligente o malintenzionato
 - attraverso copie di riserva insicure
 - attraverso malware installato in alcune applicazioni (browser, lettori PDF,
   eccetera)
 - attraverso coercizione quando attraversate confini internazionali
 
 Proteggere la vostra chiave con una buona passphare aiuta notevolmente a
 ridurre i rischi elencati qui sopra, ma le passphrase possono essere scoperte
 attraverso i keylogger, il shoulder-surfing, o altri modi. Per questi motivi,
 nella configurazione si raccomanda di rimuove la chiave primaria dalla vostra
 cartella home e la si archivia su un dispositivo disconnesso.
 
 .. warning::
 
     Per favore, fate riferimento alla sezione precedente e assicuratevi
     di aver fatto una copia di riserva totale della cartella GnuPG. Quello
     che stiamo per fare renderà la vostra chiave inutile se non avete delle
     copie di riserva utilizzabili!
 
 Per prima cosa, identificate il keygrip della vostra chiave primaria::
 
     $ gpg --with-keygrip --list-key [fpr]
 
 L'output assomiglierà a questo::
 
     pub   rsa2048 2018-01-24 [SC] [expires: 2020-01-24]
           000000000000000000000000AAAABBBBCCCCDDDD
           Keygrip = 1111000000000000000000000000000000000000
     uid           [ultimate] Alice Dev <adev@kernel.org>
     sub   rsa2048 2018-01-24 [E] [expires: 2020-01-24]
           Keygrip = 2222000000000000000000000000000000000000
     sub   ed25519 2018-01-24 [S]
           Keygrip = 3333000000000000000000000000000000000000
 
 Trovate la voce keygrid che si trova sotto alla riga ``pub`` (appena sotto
 all'impronta digitale della chiave primaria). Questo corrisponderà direttamente
 ad un file nella cartella ``~/.gnupg``::
 
     $ cd ~/.gnupg/private-keys-v1.d
     $ ls
     1111000000000000000000000000000000000000.key
     2222000000000000000000000000000000000000.key
     3333000000000000000000000000000000000000.key
 
 Quello che dovrete fare è rimuovere il file .key che corrisponde al keygrip
 della chiave primaria::
 
     $ cd ~/.gnupg/private-keys-v1.d
     $ rm 1111000000000000000000000000000000000000.key
 
 Ora, se eseguite il comando ``--list-secret-keys``, vedrete che la chiave
 primaria non compare più (il simbolo ``#`` indica che non è disponibile)::
 
     $ gpg --list-secret-keys
     sec#  rsa2048 2018-01-24 [SC] [expires: 2020-01-24]
           000000000000000000000000AAAABBBBCCCCDDDD
     uid           [ultimate] Alice Dev <adev@kernel.org>
     ssb   rsa2048 2018-01-24 [E] [expires: 2020-01-24]
     ssb   ed25519 2018-01-24 [S]
 
 Dovreste rimuovere anche i file ``secring.gpg`` che si trovano nella cartella
 ``~/.gnupg``, in quanto rimasugli delle versioni precedenti di GnuPG.
 
 Se non avete la cartella "private-keys-v1.d"
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
 Se non avete la cartella ``~/.gnupg/private-keys-v1.d``, allora le vostre
 chiavi segrete sono ancora salvate nel vecchio file ``secring.gpg`` usato
 da GnuPG v1. Effettuare una qualsiasi modifica alla vostra chiave, come
 cambiare la passphare o aggiungere una sottochiave, dovrebbe convertire
 automaticamente il vecchio formato ``secring.gpg``nel nuovo
 ``private-keys-v1.d``.
 
 Una volta che l'avete fatto, assicuratevi di rimuovere il file ``secring.gpg``,
 che continua a contenere la vostra chiave privata.
 
 .. _it_smartcards:
 
 Spostare le sottochiavi in un apposito dispositivo criptato
 ===========================================================
 
 Nonostante la chiave primaria sia ora al riparo da occhi e mani indiscrete,
 le sottochiavi si trovano ancora nella vostra cartella home. Chiunque riesca
 a mettere le sue mani su quelle chiavi riuscirà a decriptare le vostre
 comunicazioni o a falsificare le vostre firme (se conoscono la passphrase).
 Inoltre, ogni volta che viene fatta un'operazione con GnuPG, le chiavi vengono
 caricate nella memoria di sistema e potrebbero essere rubate con l'uso di
 malware sofisticati (pensate a Meltdown e a Spectre).
 
 Il miglior modo per proteggere le proprie chiave è di spostarle su un
 dispositivo specializzato in grado di effettuare operazioni smartcard.
 
 I benefici di una smartcard
 ---------------------------
 
 Una smartcard contiene un chip crittografico che è capace di immagazzinare
 le chiavi private ed effettuare operazioni crittografiche direttamente sulla
 carta stessa. Dato che la chiave non lascia mai la smartcard, il sistema
 operativo usato sul computer non sarà in grado di accedere alle chiavi.
 Questo è molto diverso dai dischi USB criptati che abbiamo usato allo scopo di
 avere una copia di riserva sicura -- quando il dispositivo USB è connesso e
 montato, il sistema operativo potrà accedere al contenuto delle chiavi private.
 
 L'uso di un disco USB criptato non può sostituire le funzioni di un dispositivo
 capace di operazioni di tipo smartcard.
 
 Dispositivi smartcard disponibili
 ---------------------------------
 
 A meno che tutti i vostri computer dispongano di lettori smartcard, il modo
 più semplice è equipaggiarsi di un dispositivo USB specializzato che
 implementi le funzionalità delle smartcard.  Sul mercato ci sono diverse
 soluzioni disponibili:
 
 - `Nitrokey Start`_: è Open hardware e Free Software, è basata sul progetto
   `GnuK`_ della FSIJ. Questo è uno dei pochi dispositivi a supportare le chiavi
   ECC ED25519, ma offre meno funzionalità di sicurezza (come la resistenza
   alla manomissione o alcuni attacchi ad un canale laterale).
 - `Nitrokey Pro 2`_: è simile alla Nitrokey Start, ma è più resistente alla
   manomissione e offre più funzionalità di sicurezza. La Pro 2 supporta la
   crittografia ECC (NISTP).
 - `Yubikey 5`_: l'hardware e il software sono proprietari, ma è più economica
   della  Nitrokey Pro ed è venduta anche con porta USB-C il che è utile con i
   computer portatili più recenti. In aggiunta, offre altre funzionalità di
   sicurezza come FIDO, U2F, e ora supporta anche le chiavi ECC (NISTP)
 
 `Su LWN c'è una buona recensione`_ dei modelli elencati qui sopra e altri.
 La scelta dipenderà dal costo, dalla disponibilità nella vostra area
 geografica e vostre considerazioni sull'hardware aperto/proprietario.
 
 Se volete usare chiavi ECC, la vostra migliore scelta sul mercato è la
 Nitrokey Start.
 
 .. _`Nitrokey Start`: https://shop.nitrokey.com/shop/product/nitrokey-start-6
 .. _`Nitrokey Pro 2`: https://shop.nitrokey.com/shop/product/nitrokey-pro-2-3
 .. _`Yubikey 5`: https://www.yubico.com/product/yubikey-5-overview/
 .. _Gnuk: http://www.fsij.org/doc-gnuk/
 .. _`Su LWN c'è una buona recensione`: https://lwn.net/Articles/736231/
 
 Configurare il vostro dispositivo smartcard
 -------------------------------------------
 
 Il vostro dispositivo smartcard dovrebbe iniziare a funzionare non appena
 lo collegate ad un qualsiasi computer Linux moderno. Potete verificarlo
 eseguendo::
 
     $ gpg --card-status
 
 Se vedete tutti i dettagli della smartcard, allora ci siamo. Sfortunatamente,
 affrontare tutti i possibili motivi per cui le cose potrebbero non funzionare
 non è lo scopo di questa guida. Se avete problemi nel far funzionare la carta
 con GnuPG, cercate aiuto attraverso i soliti canali di supporto.
 
 Per configurare la vostra smartcard, dato che non c'è una via facile dalla
 riga di comando, dovrete usate il menu di GnuPG::
 
     $ gpg --card-edit
     [...omitted...]
     gpg/card> admin
     Admin commands are allowed
     gpg/card> passwd
 
 Dovreste impostare il PIN dell'utente (1), quello dell'amministratore (3) e il
 codice di reset (4). Assicuratevi di annotare e salvare questi codici in un
 posto sicuro -- specialmente il PIN dell'amministratore e il codice di reset
 (che vi permetterà di azzerare completamente la smartcard).  Il PIN
 dell'amministratore viene usato così raramente che è inevitabile dimenticarselo
 se non lo si annota.
 
 Tornando al nostro menu, potete impostare anche altri valori (come il nome,
 il sesso, informazioni d'accesso, eccetera), ma non sono necessari e aggiunge
 altre informazioni sulla carta che potrebbero trapelare in caso di smarrimento.
 
 .. note::
 
     A dispetto del nome "PIN", né il PIN utente né quello dell'amministratore
     devono essere esclusivamente numerici.
 
 Spostare le sottochiavi sulla smartcard
 ---------------------------------------
 
 Uscite dal menu (usando "q") e salverete tutte le modifiche. Poi, spostiamo
 tutte le sottochiavi sulla smartcard. Per la maggior parte delle operazioni
 vi serviranno sia la passphrase della chiave PGP che il PIN
 dell'amministratore::
 
     $ gpg --edit-key [fpr]
 
     Secret subkeys are available.
 
     pub  rsa2048/AAAABBBBCCCCDDDD
          created: 2018-01-23  expires: 2020-01-23  usage: SC
          trust: ultimate      validity: ultimate
     ssb  rsa2048/1111222233334444
          created: 2018-01-23  expires: never       usage: E
     ssb  ed25519/5555666677778888
          created: 2017-12-07  expires: never       usage: S
     [ultimate] (1). Alice Dev <adev@kernel.org>
 
     gpg>
 
 Usando ``--edit-key`` si tornerà alla modalità menu e noterete che
 la lista delle chiavi è leggermente diversa. Da questo momento in poi,
 tutti i comandi saranno eseguiti nella modalità menu, come indicato
 da ``gpg>``.
 
 Per prima cosa, selezioniamo la chiave che verrà messa sulla carta --
 potete farlo digitando ``key 1`` (è la prima della lista, la sottochiave
 **[E]**)::
 
     gpg> key 1
 
 Nel'output dovreste vedere ``ssb*`` associato alla chiave **[E]**. Il simbolo
 ``*`` indica che la chiave è stata "selezionata". Funziona come un
 interruttore, ovvero se scrivete nuovamente ``key 1``, il simbolo ``*`` sparirà
 e la chiave non sarà più selezionata.
 
 Ora, spostiamo la chiave sulla smartcard::
 
     gpg> keytocard
     Please select where to store the key:
        (2) Encryption key
     Your selection? 2
 
 Dato che è la nostra chiave  **[E]**, ha senso metterla nella sezione criptata.
 Quando confermerete la selezione, vi verrà chiesta la passphrase della vostra
 chiave PGP, e poi il PIN dell'amministratore. Se il comando ritorna senza
 errori, allora la vostra chiave è stata spostata con successo.
 
 **Importante**: digitate nuovamente ``key 1`` per deselezionare la prima chiave
 e selezionate la seconda chiave **[S]** con ``key 2``::
 
     gpg> key 1
     gpg> key 2
     gpg> keytocard
     Please select where to store the key:
        (1) Signature key
        (3) Authentication key
     Your selection? 1
 
 Potete usare la chiave **[S]** sia per firmare che per autenticare, ma vogliamo
 che sia nella sezione di firma, quindi scegliete (1). Ancora una volta, se il
 comando ritorna senza errori, allora l'operazione è avvenuta con successo::
 
     gpg> q
     Save changes? (y/N) y
 
 Salvando le modifiche cancellerete dalla vostra cartella home tutte le chiavi
 che avete spostato sulla carta (ma questo non è un problema, perché abbiamo
 fatto delle copie di sicurezza nel caso in cui dovessimo configurare una
 nuova smartcard).
 
 Verificare che le chiavi siano state spostate
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
 Ora, se doveste usare l'opzione ``--list-secret-keys``, vedrete una
 sottile differenza nell'output::
 
     $ gpg --list-secret-keys
     sec#  rsa2048 2018-01-24 [SC] [expires: 2020-01-24]
           000000000000000000000000AAAABBBBCCCCDDDD
     uid           [ultimate] Alice Dev <adev@kernel.org>
     ssb>  rsa2048 2018-01-24 [E] [expires: 2020-01-24]
     ssb>  ed25519 2018-01-24 [S]
 
 Il simbolo ``>`` in ``ssb>`` indica che la sottochiave è disponibile solo
 nella smartcard. Se tornate nella vostra cartella delle chiavi segrete e
 guardate al suo contenuto, noterete che i file ``.key`` sono stati sostituiti
 con degli stub::
 
     $ cd ~/.gnupg/private-keys-v1.d
     $ strings *.key | grep 'private-key'
 
 Per indicare che i file sono solo degli stub e che in realtà il contenuto è
 sulla smartcard, l'output dovrebbe mostrarvi ``shadowed-private-key``.
 
 Verificare che la smartcard funzioni
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
 Per verificare che la smartcard funzioni come dovuto, potete creare
 una firma::
 
     $ echo "Hello world" | gpg --clearsign > /tmp/test.asc
     $ gpg --verify /tmp/test.asc
 
 Col primo comando dovrebbe chiedervi il PIN della smartcard, e poi dovrebbe
 mostrare "Good signature" dopo l'esecuzione di ``gpg --verify``.
 
 Complimenti, siete riusciti a rendere estremamente difficile il furto della
 vostra identità digitale di sviluppatore.
 
 Altre operazioni possibili con GnuPG
 ------------------------------------
 
 Segue un breve accenno ad alcune delle operazioni più comuni che dovrete
 fare con le vostre chiavi PGP.
 
 Montare il disco con la chiave primaria
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
 Vi servirà la vostra chiave principale per tutte le operazioni che seguiranno,
 per cui per prima cosa dovrete accedere ai vostri backup e dire a GnuPG di
 usarli::
 
     $ export GNUPGHOME=/media/disk/foo/gnupg-backup
     $ gpg --list-secret-keys
 
 Dovete assicurarvi di vedere ``sec`` e non ``sec#`` nell'output del programma
 (il simbolo ``#`` significa che la chiave non è disponibile e che state ancora
 utilizzando la vostra solita cartella di lavoro).
 
 Estendere la data di scadenza di una chiave
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
 La chiave principale ha una data di scadenza di 2 anni dal momento della sua
 creazione. Questo per motivi di sicurezza e per rendere obsolete le chiavi
 che, eventualmente, dovessero sparire dai keyserver.
 
 Per estendere di un anno, dalla data odierna, la scadenza di una vostra chiave,
 eseguite::
 
     $ gpg --quick-set-expire [fpr] 1y
 
 Se per voi è più facile da memorizzare, potete anche utilizzare una data
 specifica (per esempio, il vostro compleanno o capodanno)::
 
     $ gpg --quick-set-expire [fpr] 2020-07-01
 
 Ricordatevi di inviare l'aggiornamento ai keyserver::
 
     $ gpg --send-key [fpr]
 
 Aggiornare la vostra cartella di lavoro dopo ogni modifica
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
 Dopo aver fatto delle modifiche alle vostre chiavi usando uno spazio a parte,
 dovreste importarle nella vostra cartella di lavoro abituale::
 
     $ gpg --export | gpg --homedir ~/.gnupg --import
     $ unset GNUPGHOME
 
 
 Usare PGP con Git
 =================
 
 Una delle caratteristiche fondanti di Git è la sua natura decentralizzata --
 una volta che il repositorio è stato clonato sul vostro sistema, avete la
 storia completa del progetto, inclusi i suoi tag, i commit ed i rami. Tuttavia,
 con i centinaia di repositori clonati che ci sono in giro, come si fa a
 verificare che la loro copia di linux.git non è stata manomessa da qualcuno?
 
 Oppure, cosa succede se viene scoperta una backdoor nel codice e la riga
 "Autore" dice che sei stato tu, mentre tu sei abbastanza sicuro di
 `non averci niente a che fare`_?
 
 Per risolvere entrambi i problemi, Git ha introdotto l'integrazione con PGP.
 I tag firmati dimostrano che il repositorio è integro assicurando che il suo
 contenuto è lo stesso che si trova sulle macchine degli sviluppatori che hanno
 creato il tag; mentre i commit firmati rendono praticamente impossibile
 ad un malintenzionato di impersonarvi senza avere accesso alle vostre chiavi
 PGP.
 
 .. _`non averci niente a che fare`: https://github.com/jayphelps/git-blame-someone-else
 
 Configurare git per usare la vostra chiave PGP
 ----------------------------------------------
 
 Se avete solo una chiave segreta nel vostro portachiavi, allora non avete nulla
 da fare in più dato che sarà la vostra chiave di base. Tuttavia, se doveste
 avere più chiavi segrete, potete dire a git quale dovrebbe usare (``[fpg]``
 è la vostra impronta digitale)::
 
     $ git config --global user.signingKey [fpr]
 
 **IMPORTANTE**: se avete una comando dedicato per ``gpg2``, allora dovreste
 dire a git di usare sempre quello piuttosto che il vecchio comando ``gpg``::
 
     $ git config --global gpg.program gpg2
 
 Come firmare i tag
 ------------------
 
 Per creare un tag firmato, passate l'opzione ``-s`` al comando tag::
 
     $ git tag -s [tagname]
 
 La nostra raccomandazione è quella di firmare sempre i tag git, perché
 questo permette agli altri sviluppatori di verificare che il repositorio
 git dal quale stanno prendendo il codice non è stato alterato intenzionalmente.
 
 Come verificare i tag firmati
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
 Per verificare un tag firmato, potete usare il comando ``verify-tag``::
 
     $ git verify-tag [tagname]
 
 Se state prendendo un tag da un fork del repositorio del progetto, git
 dovrebbe verificare automaticamente la firma di quello che state prendendo
 e vi mostrerà il risultato durante l'operazione di merge::
 
     $ git pull [url] tags/sometag
 
 Il merge conterrà qualcosa di simile::
 
     Merge tag 'sometag' of [url]
 
     [Tag message]
 
     # gpg: Signature made [...]
     # gpg: Good signature from [...]
 
 Se state verificando il tag di qualcun altro, allora dovrete importare
 la loro chiave PGP. Fate riferimento alla sezione ":ref:`it_verify_identities`"
 che troverete più avanti.
 
 Configurare git per firmare sempre i tag con annotazione
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
 Se state creando un tag con annotazione è molto probabile che vogliate
 firmarlo. Per imporre a git di firmare sempre un tag con annotazione,
 dovete impostare la seguente opzione globale::
 
     $ git config --global tag.forceSignAnnotated true
 
 Come usare commit firmati
 -------------------------
 
 Creare dei commit firmati è facile, ma è molto più difficile utilizzarli
 nello sviluppo del kernel linux per via del fatto che ci si affida alle
 liste di discussione e questo modo di procedere non mantiene le firme PGP
 nei commit. In aggiunta, quando si usa *rebase* nel proprio repositorio
 locale per allinearsi al kernel anche le proprie firme PGP verranno scartate.
 Per questo motivo, la maggior parte degli sviluppatori del kernel non si
 preoccupano troppo di firmare i propri commit ed ignoreranno quelli firmati
 che si trovano in altri repositori usati per il proprio lavoro.
 
 Tuttavia, se avete il vostro repositorio di lavoro disponibile al pubblico
 su un qualche servizio di hosting git (kernel.org, infradead.org, ozlabs.org,
 o altri), allora la raccomandazione è di firmare tutti i vostri commit
 anche se gli sviluppatori non ne beneficeranno direttamente.
 
 Vi raccomandiamo di farlo per i seguenti motivi:
 
 1. Se dovesse mai esserci la necessità di fare delle analisi forensi o
    tracciare la provenienza di un codice, anche sorgenti mantenuti
    esternamente che hanno firme PGP sui commit avranno un certo valore a
    questo scopo.
 2. Se dovesse mai capitarvi di clonare il vostro repositorio locale (per
    esempio dopo un danneggiamento del disco), la firma vi permetterà di
    verificare l'integrità del repositorio prima di riprendere il lavoro.
 3. Se qualcuno volesse usare *cherry-pick* sui vostri commit, allora la firma
    permetterà di verificare l'integrità dei commit prima di applicarli.
 
 Creare commit firmati
 ~~~~~~~~~~~~~~~~~~~~~
 
 Per creare un commit firmato, dovete solamente aggiungere l'opzione ``-S``
 al comando ``git commit`` (si usa la lettera maiuscola per evitare
 conflitti con un'altra opzione)::
 
     $ git commit -S
 
 Configurare git per firmare sempre i commit
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
 Potete dire a git di firmare sempre i commit::
 
     git config --global commit.gpgSign true
 
 .. note::
 
     Assicuratevi di aver configurato ``gpg-agent`` prima di abilitare
     questa opzione.
 
 .. _it_verify_identities:
 
 Come verificare l'identità degli sviluppatori del kernel
 ========================================================
 
 Firmare i tag e i commit è facile, ma come si fa a verificare che la chiave
 usata per firmare qualcosa appartenga davvero allo sviluppatore e non ad un
 impostore?
 
 Configurare l'auto-key-retrieval usando WKD e DANE
 --------------------------------------------------
 
 Se non siete ancora in possesso di una vasta collezione di chiavi pubbliche
 di altri sviluppatori, allora potreste iniziare il vostro portachiavi
 affidandovi ai servizi di auto-scoperta e auto-recupero. GnuPG può affidarsi
 ad altre tecnologie di delega della fiducia, come DNSSEC e TLS, per sostenervi
 nel caso in cui iniziare una propria rete di fiducia da zero sia troppo
 scoraggiante.
 
 Aggiungete il seguente testo al vostro file ``~/.gnupg/gpg.conf``::
 
     auto-key-locate wkd,dane,local
     auto-key-retrieve
 
 La *DNS-Based Authentication of Named Entities* ("DANE") è un metodo
 per la pubblicazione di chiavi pubbliche su DNS e per renderle sicure usando
 zone firmate con DNSSEC. Il *Web Key Directory* ("WKD") è un metodo
 alternativo che usa https a scopo di ricerca. Quando si usano DANE o WKD
 per la ricerca di chiavi pubbliche, GnuPG validerà i certificati DNSSEC o TLS
 prima di aggiungere al vostro portachiavi locale le eventuali chiavi trovate.
 
 Kernel.org pubblica la WKD per tutti gli sviluppatori che hanno un account
 kernel.org. Una volta che avete applicato le modifiche al file ``gpg.conf``,
 potrete auto-recuperare le chiavi di Linus Torvalds e Greg Kroah-Hartman
 (se non le avete già)::
 
     $ gpg --locate-keys torvalds@kernel.org gregkh@kernel.org
 
 Se avete un account kernel.org, al fine di rendere più utile l'uso di WKD
 da parte di altri sviluppatori del kernel, dovreste `aggiungere alla vostra
 chiave lo UID di kernel.org`_.
 
 .. _`aggiungere alla vostra chiave lo UID di kernel.org`: https://korg.wiki.kernel.org/userdoc/mail#adding_a_kernelorg_uid_to_your_pgp_key
 
 Web of Trust (WOT) o Trust on First Use (TOFU)
 ----------------------------------------------
 
 PGP incorpora un meccanismo di delega della fiducia conosciuto come
 "Web of Trust". Di base, questo è un tentativo di sostituire la necessità
 di un'autorità certificativa centralizzata tipica del mondo HTTPS/TLS.
 Invece di avere svariati produttori software che decidono chi dovrebbero
 essere le entità di certificazione di cui dovreste fidarvi, PGP lascia
 la responsabilità ad ogni singolo utente.
 
 Sfortunatamente, solo poche persone capiscono come funziona la rete di fiducia.
 Nonostante sia un importante aspetto della specifica OpenPGP, recentemente
 le versioni di GnuPG (2.2 e successive) hanno implementato un meccanisco
 alternativo chiamato "Trust on First Use" (TOFU). Potete pensare a TOFU come
 "ad un approccio all fidicia simile ad SSH". In SSH, la prima volta che vi
 connettete ad un sistema remoto, l'impronta digitale della chiave viene
 registrata e ricordata. Se la chiave dovesse cambiare in futuro, il programma
 SSH vi avviserà e si rifiuterà di connettersi, obbligandovi a prendere una
 decisione circa la fiducia che riponete nella nuova chiave. In modo simile,
 la prima volta che importate la chiave PGP di qualcuno, si assume sia valida.
 Se ad un certo punto GnuPG trova un'altra chiave con la stessa identità,
 entrambe, la vecchia e la nuova, verranno segnate come invalide e dovrete
 verificare manualmente quale tenere.
 
 Vi raccomandiamo di usare il meccanisco TOFU+PGP (che è la nuova configurazione
 di base di GnuPG v2). Per farlo, aggiungete (o modificate) l'impostazione
 ``trust-model`` in ``~/.gnupg/gpg.conf``::
 
     trust-model tofu+pgp
 
 Come usare i keyserver in sicurezza
 -----------------------------------
 Se ottenete l'errore "No public key" quando cercate di validate il tag di
 qualcuno, allora dovreste cercare quella chiave usando un keyserver. È
 importante tenere bene a mente che non c'è alcuna garanzia che la chiave
 che avete recuperato da un keyserver PGP appartenga davvero alla persona
 reale -- è progettato così. Dovreste usare il Web of Trust per assicurarvi
 che la chiave sia valida.
 
 Come mantenere il Web of Trust va oltre gli scopi di questo documento,
 semplicemente perché farlo come si deve richiede sia sforzi che perseveranza
 che tendono ad andare oltre al livello di interesse della maggior parte degli
 esseri umani. Qui di seguito alcuni rapidi suggerimenti per aiutarvi a ridurre
 il rischio di importare chiavi maligne.
 
 Primo, diciamo che avete provato ad eseguire ``git verify-tag`` ma restituisce
 un errore dicendo che la chiave non è stata trovata::
 
     $ git verify-tag sunxi-fixes-for-4.15-2
     gpg: Signature made Sun 07 Jan 2018 10:51:55 PM EST
     gpg:                using RSA key DA73759BF8619E484E5A3B47389A54219C0F2430
     gpg:                issuer "wens@...org"
     gpg: Can't check signature: No public key
 
 Cerchiamo nel keyserver per maggiori informazioni sull'impronta digitale
 della chiave (l'impronta digitale, probabilmente, appartiene ad una
 sottochiave, dunque non possiamo usarla direttamente senza trovare prima
 l'ID della chiave primaria associata ad essa)::
 
     $ gpg --search DA73759BF8619E484E5A3B47389A54219C0F2430
     gpg: data source: hkp://keys.gnupg.net
     (1) Chen-Yu Tsai <wens@...org>
           4096 bit RSA key C94035C21B4F2AEB, created: 2017-03-14, expires: 2019-03-15
     Keys 1-1 of 1 for "DA73759BF8619E484E5A3B47389A54219C0F2430".  Enter number(s), N)ext, or Q)uit > q
 
 Localizzate l'ID della chiave primaria, nel nostro esempio
 ``C94035C21B4F2AEB``. Ora visualizzate le chiavi di Linus Torvalds
 che avete nel vostro portachiavi::
 
     $ gpg --list-key torvalds@kernel.org
     pub   rsa2048 2011-09-20 [SC]
           ABAF11C65A2970B130ABE3C479BE3E4300411886
     uid           [ unknown] Linus Torvalds <torvalds@kernel.org>
     sub   rsa2048 2011-09-20 [E]
 
 Poi, cercate un percorso affidabile da Linux Torvalds alla chiave che avete
 trovato con ``gpg --search`` usando la chiave sconosciuta.Per farlo potete usare
 diversi strumenti come https://github.com/mricon/wotmate,
 https://git.kernel.org/pub/scm/docs/kernel/pgpkeys.git/tree/graphs, e
 https://the.earth.li/~noodles/pathfind.html.
 
 Se trovate un paio di percorsi affidabili è un buon segno circa la validità
 della chiave. Ora, potete aggiungerla al vostro portachiavi dal keyserver::
 
     $ gpg --recv-key C94035C21B4F2AEB
 
 Questa procedura non è perfetta, e ovviamente state riponendo la vostra
 fiducia nell'amministratore del servizio *PGP Pathfinder* sperando che non
 sia malintenzionato (infatti, questo va contro :ref:`it_devs_not_infra`).
 Tuttavia, se mantenete con cura la vostra rete di fiducia sarà un deciso
 miglioramento rispetto alla cieca fiducia nei keyserver.

This page was automatically generated by the 2.1.0 LXR engine. The LXR team