code:
.. 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.


code:
.. SPDX-License-Identifier: GPL-2.0

.. include:: ../disclaimer-ita.rst

:Original: Documentation/process/maintainer-tip.rst

Il tascabile dei sorgenti tip
=============================

.. note:: To be translated

repo_name: angery/linux


code:
:Original: Documentation/process/maintainers.rst

Lista dei manutentori e come inviare modifiche al kernel
========================================================

Questa pagina non verrà tradotta. Fate riferimento alla versione originale in
inglese.

.. note:: La pagina originale usa una direttiva speciale per integrare il file
          `MAINTAINERS` in sphinx. La parte di quel documento che si potrebbe
          tradurre contiene comunque informazioni già presenti in
          :ref:`Documentation/translations/it_IT/process/submitting-patches.rst
          <it_submittingpatches>`.


code:
.. include:: ../disclaimer-ita.rst

:Original: :doc:`../../../process/management-style`
:Translator: Alessia Mantegazza <amantegazza@vaga.pv.it>

.. _it_managementstyle:

Il modello di gestione del kernel Linux
=======================================

Questo breve documento descrive il modello di gestione del kernel Linux.
Per certi versi, esso rispecchia il documento
:ref:`translations/it_IT/process/coding-style.rst <it_codingstyle>`,
ed è principalmente scritto per evitare di rispondere [#f1]_ in continuazione
alle stesse identiche (o quasi) domande.

Il modello di gestione è qualcosa di molto personale e molto più difficile da
qualificare rispetto a delle semplici regole di codifica, quindi questo
documento potrebbe avere più o meno a che fare con la realtà.  È cominciato
come un gioco, ma ciò non significa che non possa essere vero.
Lo dovrete decidere voi stessi.

In ogni caso, quando si parla del "dirigente del kernel", ci si riferisce
sempre alla persona che dirige tecnicamente, e non a coloro che
tradizionalmente hanno un ruolo direttivo all'interno delle aziende.  Se vi
occupate di convalidare acquisti o avete una qualche idea sul budget del vostro
gruppo, probabilmente non siete un dirigente del kernel.  Quindi i suggerimenti
qui indicati potrebbero fare al caso vostro, oppure no.

Prima di tutto, suggerirei di acquistare "Le sette regole per avere successo",
e di non leggerlo. Bruciatelo, è un grande gesto simbolico.

.. [#f1] Questo documento non fa molto per risponde alla domanda, ma rende
	 così dannatamente ovvio a chi la pone che non abbiamo la minima idea
	 di come rispondere.

Comunque, partiamo:

.. _it_decisions:

1) Le decisioni
---------------

Tutti pensano che i dirigenti decidano, e che questo prendere decisioni
sia importante.  Più grande e dolorosa è la decisione, più importante deve
essere il dirigente che la prende.  Questo è molto profondo ed ovvio, ma non è
del tutto vero.

Il gioco consiste nell'"evitare" di dover prendere decisioni.  In particolare
se qualcuno vi chiede di "Decidere" tra (a) o (b), e vi dice che ha
davvero bisogno di voi per questo, come dirigenti siete nei guai.
Le persone che gestite devono conoscere i dettagli più di quanto li conosciate
voi, quindi se vengono da voi per una decisione tecnica, siete fottuti.
Non sarete chiaramente competente per prendere quella decisione per loro.

(Corollario: se le persone che gestite non conoscono i dettagli meglio di voi,
anche in questo caso sarete fregati, tuttavia per altre ragioni.  Ossia state
facendo il lavoro sbagliato, e che invece dovrebbero essere "loro" a gestirvi)

Quindi il gioco si chiama "evitare" decisioni, almeno le più grandi e
difficili.  Prendere decisioni piccoli e senza conseguenze va bene, e vi fa
sembrare competenti in quello che state facendo, quindi quello che un dirigente
del kernel ha bisogno di fare è trasformare le decisioni grandi e difficili
in minuzie delle quali nessuno importa.

Ciò aiuta a capire che la differenza chiave tra una grande decisione ed una
piccola sta nella possibilità di modificare tale decisione in seguito.
Qualsiasi decisione importante può essere ridotta in decisioni meno importanti,
ma dovete assicurarvi che possano essere reversibili in caso di errori
(presenti o futuri).  Improvvisamente, dovrete essere doppiamente dirigenti
per **due** decisioni non sequenziali - quella sbagliata **e** quella giusta.

E le persone vedranno tutto ciò come prova di vera capacità di comando
(*cough* cavolata *cough*)

Così la chiave per evitare le decisioni difficili diviene l'evitare
di fare cose che non possono essere disfatte.  Non infilatevi in un angolo
dal quale non potrete sfuggire.  Un topo messo all'angolo può rivelarsi
pericoloso - un dirigente messo all'angolo è solo pietoso.

**In ogni caso** dato che nessuno è stupido al punto da lasciare veramente ad
un dirigente del kernel un enorme responsabilità, solitamente è facile fare
marcia indietro. Annullare una decisione è molto facile: semplicemente dite a
tutti che siete stati degli scemi incompetenti, dite che siete dispiaciuti, ed
annullate tutto l'inutile lavoro sul quale gli altri hanno lavorato nell'ultimo
anno.  Improvvisamente la decisione che avevate preso un anno fa non era poi
così grossa, dato che può essere facilmente annullata.

È emerso che alcune persone hanno dei problemi con questo tipo di approccio,
questo per due ragioni:

 - ammettere di essere degli idioti è più difficile di quanto sembri.  A tutti
   noi piace mantenere le apparenze, ed uscire allo scoperto in pubblico per
   ammettere che ci si è sbagliati è qualcosa di davvero impegnativo.
 - avere qualcuno che ti dice che ciò su cui hai lavorato nell'ultimo anno
   non era del tutto valido, può rivelarsi difficile anche per un povero ed
   umile ingegnere, e mentre il **lavoro** vero era abbastanza facile da
   cancellare, dall'altro canto potreste aver irrimediabilmente perso la
   fiducia di quell'ingegnere.  E ricordate che l'"irrevocabile" era quello
   che avevamo cercato di evitare fin dall'inizio, e la vostra decisione
   ha finito per esserlo.

Fortunatamente, entrambe queste ragioni posso essere mitigate semplicemente
ammettendo fin dal principio che non avete una cavolo di idea, dicendo
agli altri in anticipo che la vostra decisione è puramente ipotetica, e che
potrebbe essere sbagliata.  Dovreste sempre riservarvi il diritto di cambiare
la vostra opinione, e rendere gli altri ben **consapevoli** di ciò.
Ed è molto più facile ammettere di essere stupidi quando non avete **ancora**
fatto quella cosa stupida.

Poi, quando è realmente emersa la vostra stupidità, le persone semplicemente
roteeranno gli occhi e diranno "Uffa, no, ancora".

Questa ammissione preventiva di incompetenza potrebbe anche portare le persone
che stanno facendo il vero lavoro, a pensarci due volte.  Dopo tutto, se
**loro** non sono certi se sia una buona idea, voi, sicuro come la morte,
non dovreste incoraggiarli promettendogli che ciò su cui stanno lavorando
verrà incluso.  Fate si che ci pensino due volte prima che si imbarchino in un
grosso lavoro.

Ricordate: loro devono sapere più cose sui dettagli rispetto a voi, e
solitamente pensano di avere già la risposta a tutto. La miglior cosa che
potete fare in qualità di dirigente è di non instillare troppa fiducia, ma
invece fornire una salutare dose di pensiero critico su quanto stanno facendo.

Comunque, un altro modo di evitare una decisione è quello di lamentarsi
malinconicamente dicendo : "non possiamo farli entrambi e basta?" e con uno
sguardo pietoso.  Fidatevi, funziona.  Se non è chiaro quale sia il miglior
approccio, lo scopriranno.  La risposta potrebbe essere data dal fatto che
entrambe i gruppi di lavoro diventano frustati al punto di rinunciarvi.

Questo può suonare come un fallimento, ma di solito questo è un segno che
c'era qualcosa che non andava in entrambe i progetti, e il motivo per
il quale le persone coinvolte non abbiano potuto decidere era che entrambe
sbagliavano.  Voi ne uscirete freschi come una rosa, e avrete evitato un'altra
decisione con la quale avreste potuto fregarvi.

2) Le persone
-------------

Ci sono molte persone stupide, ed essere un dirigente significa che dovrete
scendere a patti con questo, e molto più importate, che **loro** devono avere
a che fare con **voi**.

Ne emerge che mentre è facile annullare degli errori tecnici, non è invece
così facile rimuovere i disordini della personalità.  Dovrete semplicemente
convivere con i loro, ed i vostri, problemi.

Comunque, al fine di preparavi in qualità di dirigenti del kernel, è meglio
ricordare di non abbattere alcun ponte, bombardare alcun paesano innocente,
o escludere troppi sviluppatori kernel. Ne emerge che escludere le persone
è piuttosto facile, mentre includerle nuovamente è difficile. Così
"l'esclusione" immediatamente cade sotto il titolo di "non reversibile", e
diviene un no-no secondo la sezione :ref:`it_decisions`.

Esistono alcune semplici regole qui:

 (1) non chiamate le persone teste di c*** (al meno, non in pubblico)
 (2) imparate a scusarvi quando dimenticate la regola (1)

Il problema del punto numero 1 è che è molto facile da rispettare, dato che
è possibile dire "sei una testa di c***" in milioni di modi differenti [#f2]_,
a volte senza nemmeno pensarci, e praticamente sempre con la calda convinzione
di essere nel giusto.

E più convinti sarete che avete ragione (e diciamolo, potete chiamare
praticamente **tutti** testa di c**, e spesso **sarete** nel giusto), più
difficile sarà scusarvi successivamente.

Per risolvere questo problema, avete due possibilità:

 - diventare davvero bravi nello scusarsi
 - essere amabili così che nessuno finirà col sentirsi preso di mira.  Siate
   creativi abbastanza, e potrebbero esserne divertiti.

L'opzione dell'essere immancabilmente educati non esiste proprio. Nessuno
si fiderà di qualcuno che chiaramente sta nascondendo il suo vero carattere.

.. [#f2] Paul Simon cantava: "50 modi per lasciare il vostro amante", perché,
	 molto francamente, "Un milione di modi per dire ad uno sviluppatore
	 Testa di c***" non avrebbe funzionato. Ma sono sicuro che ci abbia
	 pensato.

3) Le persone II - quelle buone
-------------------------------

Mentre emerge che la maggior parte delle persone sono stupide, il corollario
a questo è il triste fatto che anche voi siete fra queste, e che mentre
possiamo tutti crogiolarci nella sicurezza di essere migliori della media
delle persone (diciamocelo, nessuno crede di essere nelle media o sotto di
essa), dovremmo anche ammettere che non siamo il "coltello più affilato" del
circondario, e che ci saranno altre persone che sono meno stupide di quanto
lo siete voi.

Molti reagiscono male davanti alle persone intelligenti. Altri le usano a
proprio vantaggio.

Assicuratevi che voi, in qualità di manutentori del kernel, siate nel secondo
gruppo. Inchinatevi dinanzi a loro perché saranno le persone che vi renderanno
il lavoro più facile.  In particolare, prenderanno le decisioni per voi, che è
l'oggetto di questo gioco.

Quindi quando trovate qualcuno più sveglio di voi, prendetevela comoda.
Le vostre responsabilità dirigenziali si ridurranno in gran parte nel dire
"Sembra una buona idea - Vai", oppure "Sembra buono, ma invece circa questo e
quello?".  La seconda versione in particolare è una gran modo per imparare
qualcosa di nuovo circa "questo e quello" o di sembrare **extra** dirigenziali
sottolineando qualcosa alla quale i più svegli non avevano pensato.  In
entrambe i casi, vincete.

Una cosa alla quale dovete fare attenzione è che l'essere grandi in qualcosa
non si traduce automaticamente nell'essere grandi anche in altre cose.  Quindi
dovreste dare una spintarella alle persone in una specifica direzione, ma
diciamocelo, potrebbero essere bravi in ciò che fanno e far schifo in tutto
il resto.  La buona notizia è che le persone tendono a gravitare attorno a ciò
in cui sono bravi, quindi non state facendo nulla di irreversibile quando li
spingete verso una certa direzione, solo non spingete troppo.

4) Addossare le colpe
---------------------

Le cose andranno male, e le persone vogliono qualcuno da incolpare. Sarete voi.

Non è poi così difficile accettare la colpa, specialmente se le persone
riescono a capire che non era **tutta** colpa vostra.  Il che ci porta
sulla miglior strada per assumersi la colpa: fatelo per qualcun'altro.
Vi sentirete bene nel assumervi la responsabilità, e loro si sentiranno
bene nel non essere incolpati, e coloro che hanno perso i loro 36GB di
pornografia a causa della vostra incompetenza ammetteranno a malincuore che
almeno non avete cercato di fare il furbetto.

Successivamente fate in modo che gli sviluppatori che in realtà hanno fallito
(se riuscite a trovarli) sappiano **in privato** che sono "fottuti".
Questo non per fargli sapere che la prossima volta possono evitarselo ma per
fargli capire che sono in debito.  E, forse cosa più importante, sono loro che
devono sistemare la cosa.  Perché, ammettiamolo, è sicuro non sarete voi a
farlo.

Assumersi la colpa è anche ciò che vi rendere dirigenti in prima battuta.
È parte di ciò che spinge gli altri a fidarsi di voi, e vi garantisce
la gloria potenziale, perché siete gli unici a dire "Ho fatto una cavolata".
E se avete seguito le regole precedenti, sarete decisamente bravi nel dirlo.

5) Le cose da evitare
---------------------

Esiste una cosa che le persone odiano più che essere chiamate "teste di c****",
ed è essere chiamate "teste di c****" con fare da bigotto.  Se per il primo
caso potrete comunque scusarvi, per il secondo non ve ne verrà data nemmeno
l'opportunità.  Probabilmente smetteranno di ascoltarvi anche se tutto sommato
state svolgendo un buon lavoro.

Tutti crediamo di essere migliori degli altri, il che significa che quando
qualcuno inizia a darsi delle arie, ci da **davvero** fastidio.  Potreste anche
essere moralmente ed intellettualmente superiore a tutti quelli attorno a voi,
ma non cercate di renderlo ovvio per gli altri a meno che non **vogliate**
veramente far arrabbiare qualcuno [#f3]_.

Allo stesso modo evitate di essere troppo gentili e pacati.  Le buone maniere
facilmente finiscono per strabordare e nascondere i problemi, e come si usa
dire, "su internet nessuno può sentire la vostra pacatezza".  Usate argomenti
diretti per farvi capire, non potete sperare che la gente capisca in altro
modo.

Un po' di umorismo può aiutare a smorzare sia la franchezza che la moralità.
Andare oltre i limiti al punto d'essere ridicolo può portare dei punti a casa
senza renderlo spiacevole per i riceventi, i quali penseranno che stavate
facendo gli scemi.  Può anche aiutare a lasciare andare quei blocchi mentali
che abbiamo nei confronti delle critiche.

.. [#f3] Suggerimento: i forum di discussione su internet, che non sono
  collegati col vostro lavoro, sono ottimi modi per sfogare la frustrazione
  verso altre persone. Di tanto in tanto scrivete messaggi offensivi col ghigno
  in faccia per infiammare qualche discussione: vi sentirete purificati. Solo
  cercate di non cagare troppo vicino a casa.

6) Perché io?
-------------

Dato che la vostra responsabilità principale è quella di prendervi le colpe
d'altri, e rendere dolorosamente ovvio a tutti che siete degli incompetenti,
la domanda naturale che ne segue sarà : perché dovrei fare tutto ciò?

Innanzitutto, potreste diventare o no popolari al punto da avere la fila di
ragazzine (o ragazzini, evitiamo pregiudizi o sessismo) che gridano e bussano
alla porta del vostro camerino, ma comunque **proverete** un immenso senso di
realizzazione personale dall'essere "in carica".  Dimenticate il fatto che voi
state discutendo con tutti e che cercate di inseguirli il più velocemente che
potete. Tutti continueranno a pensare che voi siete la persona in carica.

È un bel lavoro se riuscite ad adattarlo a voi.


code:
.. include:: ../disclaimer-ita.rst

:Original: :ref:`Documentation/process/programming-language.rst <programming_language>`
:Translator: Federico Vaga <federico.vaga@vaga.pv.it>

.. _it_programming_language:

Linguaggio di programmazione
============================

Il kernel è scritto nel linguaggio di programmazione C [it-c-language]_.
Più precisamente, il kernel viene compilato con ``gcc`` [it-gcc]_ usando
l'opzione ``-std=gnu11`` [it-gcc-c-dialect-options]_: il dialetto GNU
dello standard ISO C11.
Linux supporta anche ``clang`` [it-clang]_, leggete la documentazione
:ref:`Building Linux with Clang/LLVM <kbuild_llvm>`.

Questo dialetto contiene diverse estensioni al linguaggio [it-gnu-extensions]_,
e molte di queste vengono usate sistematicamente dal kernel.

Il kernel offre un certo livello di supporto per la compilazione con
``icc`` [it-icc]_ su diverse architetture, tuttavia in questo momento
il supporto non è completo e richiede delle patch aggiuntive.

Attributi
---------

Una delle estensioni più comuni e usate nel kernel sono gli attributi
[it-gcc-attribute-syntax]_. Gli attributi permettono di aggiungere una semantica,
definita dell'implementazione, alle entità del linguaggio (come le variabili,
le funzioni o i tipi) senza dover fare importanti modifiche sintattiche al
linguaggio stesso (come l'aggiunta di nuove parole chiave) [it-n2049]_.

In alcuni casi, gli attributi sono opzionali (ovvero un compilatore che non
dovesse supportarli dovrebbe produrre comunque codice corretto, anche se
più lento o che non esegue controlli aggiuntivi durante la compilazione).

Il kernel definisce alcune pseudo parole chiave (per esempio ``__pure``)
in alternativa alla sintassi GNU per gli attributi (per esempio
``__attribute__((__pure__))``) allo scopo di mostrare quali funzionalità si
possono usare e/o per accorciare il codice.

Per maggiori informazioni consultate il file d'intestazione
``include/linux/compiler_attributes.h``.

.. [it-c-language] http://www.open-std.org/jtc1/sc22/wg14/www/standards
.. [it-gcc] https://gcc.gnu.org
.. [it-clang] https://clang.llvm.org
.. [it-icc] https://software.intel.com/en-us/c-compilers
.. [it-gcc-c-dialect-options] https://gcc.gnu.org/onlinedocs/gcc/C-Dialect-Options.html
.. [it-gnu-extensions] https://gcc.gnu.org/onlinedocs/gcc/C-Extensions.html
.. [it-gcc-attribute-syntax] https://gcc.gnu.org/onlinedocs/gcc/Attribute-Syntax.html
.. [it-n2049] http://www.open-std.org/jtc1/sc22/wg14/www/docs/n2049.pdf


code:
.. include:: ../disclaimer-ita.rst

:Original: :ref:`Documentation/process/stable-api-nonsense.rst <stable_api_nonsense>`
:Translator: Federico Vaga <federico.vaga@vaga.pv.it>

.. _it_stable_api_nonsense:

L'interfaccia dei driver per il kernel Linux
============================================

(tutte le risposte alle vostre domande e altro)

Greg Kroah-Hartman <greg@kroah.com>

Questo è stato scritto per cercare di spiegare perché Linux **non ha
un'interfaccia binaria, e non ha nemmeno un'interfaccia stabile**.

.. note::

   Questo articolo parla di interfacce **interne al kernel**, non delle
   interfacce verso lo spazio utente.

   L'interfaccia del kernel verso lo spazio utente è quella usata dai
   programmi, ovvero le chiamate di sistema.  Queste interfacce sono **molto**
   stabili nel tempo e non verranno modificate.  Ho vecchi programmi che sono
   stati compilati su un kernel 0.9 (circa) e tuttora funzionano sulle versioni
   2.6 del kernel.  Queste interfacce sono quelle che gli utenti e i
   programmatori possono considerare stabili.

Riepilogo generale
------------------

Pensate di volere un'interfaccia del kernel stabile, ma in realtà non la
volete, e nemmeno sapete di non volerla.  Quello che volete è un driver
stabile che funzioni, e questo può essere ottenuto solo se il driver si trova
nei sorgenti del kernel.  Ci sono altri vantaggi nell'avere il proprio driver
nei sorgenti del kernel, ognuno dei quali hanno reso Linux un sistema operativo
robusto, stabile e maturo; questi sono anche i motivi per cui avete scelto
Linux.

Introduzione
------------

Solo le persone un po' strambe vorrebbero scrivere driver per il kernel con
la costante preoccupazione per i cambiamenti alle interfacce interne.  Per il
resto del mondo, queste interfacce sono invisibili o non di particolare
interesse.

Innanzitutto, non tratterò **alcun** problema legale riguardante codice
chiuso, nascosto, avvolto, blocchi binari, o qualsia altra cosa che descrive
driver che non hanno i propri sorgenti rilasciati con licenza GPL.  Per favore
fate riferimento ad un avvocato per qualsiasi questione legale, io sono un
programmatore e perciò qui vi parlerò soltanto delle questioni tecniche (non
per essere superficiali sui problemi legali, sono veri e dovete esserne a
conoscenza in ogni circostanza).

Dunque, ci sono due tematiche principali: interfacce binarie del kernel e
interfacce stabili nei sorgenti.  Ognuna dipende dall'altra, ma discuteremo
prima delle cose binarie per toglierle di mezzo.

Interfaccia binaria del kernel
------------------------------

Supponiamo d'avere un'interfaccia stabile nei sorgenti del kernel, di
conseguenza un'interfaccia binaria dovrebbe essere anche'essa stabile, giusto?
Sbagliato.  Prendete in considerazione i seguenti fatti che riguardano il
kernel Linux:

  - A seconda della versione del compilatore C che state utilizzando, diverse
    strutture dati del kernel avranno un allineamento diverso, e possibilmente
    un modo diverso di includere le funzioni (renderle inline oppure no).
    L'organizzazione delle singole funzioni non è poi così importante, ma la
    spaziatura (*padding*) nelle strutture dati, invece, lo è.

  - In base alle opzioni che sono state selezionate per generare il kernel,
    un certo numero di cose potrebbero succedere:

      - strutture dati differenti potrebbero contenere campi differenti
      - alcune funzioni potrebbero non essere implementate (per esempio,
        alcuni *lock* spariscono se compilati su sistemi mono-processore)
      - la memoria interna del kernel può essere allineata in differenti modi
        a seconda delle opzioni di compilazione.

  - Linux funziona su una vasta gamma di architetture di processore. Non esiste
    alcuna possibilità che il binario di un driver per un'architettura funzioni
    correttamente su un'altra.

Alcuni di questi problemi possono essere risolti compilando il proprio modulo
con la stessa identica configurazione del kernel, ed usando la stessa versione
del compilatore usato per compilare il kernel.  Questo è sufficiente se volete
fornire un modulo per uno specifico rilascio su una specifica distribuzione
Linux.  Ma moltiplicate questa singola compilazione per il numero di
distribuzioni Linux e il numero dei rilasci supportati da quest'ultime e vi
troverete rapidamente in un incubo fatto di configurazioni e piattaforme
hardware (differenti processori con differenti opzioni); dunque, anche per il
singolo rilascio di un modulo, dovreste creare differenti versioni dello
stesso.

Fidatevi, se tenterete questa via, col tempo, diventerete pazzi; l'ho imparato
a mie spese molto tempo fa...

Interfaccia stabile nei sorgenti del kernel
-------------------------------------------

Se parlate con le persone che cercano di mantenere aggiornato un driver per
Linux ma che non si trova nei sorgenti, allora per queste persone l'argomento
sarà "ostico".

Lo sviluppo del kernel Linux è continuo e viaggia ad un ritmo sostenuto, e non
rallenta mai.  Perciò, gli sviluppatori del kernel trovano bachi nelle
interfacce attuali, o trovano modi migliori per fare le cose.  Se le trovano,
allora le correggeranno per migliorarle.  In questo frangente, i nomi delle
funzioni potrebbero cambiare, le strutture dati potrebbero diventare più grandi
o più piccole, e gli argomenti delle funzioni potrebbero essere ripensati.
Se questo dovesse succedere, nello stesso momento, tutte le istanze dove questa
interfaccia viene utilizzata verranno corrette, garantendo che tutto continui
a funzionare senza problemi.

Portiamo ad esempio l'interfaccia interna per il sottosistema USB che ha subito
tre ristrutturazioni nel corso della sua vita.  Queste ristrutturazioni furono
fatte per risolvere diversi problemi:

  - È stato fatto un cambiamento da un flusso di dati sincrono ad uno
    asincrono.  Questo ha ridotto la complessità di molti driver e ha
    aumentato la capacità di trasmissione di tutti i driver fino a raggiungere
    quasi la velocità massima possibile.
  - È stato fatto un cambiamento nell'allocazione dei pacchetti da parte del
    sottosistema USB per conto dei driver, cosicché ora i driver devono fornire
    più informazioni al sottosistema USB al fine di correggere un certo numero
    di stalli.

Questo è completamente l'opposto di quello che succede in alcuni sistemi
operativi proprietari che hanno dovuto mantenere, nel tempo, il supporto alle
vecchie interfacce USB.  I nuovi sviluppatori potrebbero usare accidentalmente
le vecchie interfacce e sviluppare codice nel modo sbagliato, portando, di
conseguenza, all'instabilità del sistema.

In entrambe gli scenari, gli sviluppatori hanno ritenuto che queste importanti
modifiche erano necessarie, e quindi le hanno fatte con qualche sofferenza.
Se Linux avesse assicurato di mantenere stabile l'interfaccia interna, si
sarebbe dovuto procedere alla creazione di una nuova, e quelle vecchie, e
mal funzionanti, avrebbero dovuto ricevere manutenzione, creando lavoro
aggiuntivo per gli sviluppatori del sottosistema USB.  Dato che gli
sviluppatori devono dedicare il proprio tempo a questo genere di lavoro,
chiedergli di dedicarne dell'altro, senza benefici, magari gratuitamente, non
è contemplabile.

Le problematiche relative alla sicurezza sono molto importanti per Linux.
Quando viene trovato un problema di sicurezza viene corretto in breve tempo.
A volte, per prevenire il problema di sicurezza, si sono dovute cambiare
delle interfacce interne al kernel.  Quando è successo, allo stesso tempo,
tutti i driver che usavano quelle interfacce sono stati aggiornati, garantendo
la correzione definitiva del problema senza doversi preoccupare di rivederlo
per sbaglio in futuro.  Se non si fossero cambiate le interfacce interne,
sarebbe stato impossibile correggere il problema e garantire che non si sarebbe
più ripetuto.

Nel tempo le interfacce del kernel subiscono qualche ripulita.  Se nessuno
sta più usando un'interfaccia, allora questa verrà rimossa.  Questo permette
al kernel di rimanere il più piccolo possibile, e garantisce che tutte le
potenziali interfacce sono state verificate nel limite del possibile (le
interfacce inutilizzate sono impossibili da verificare).

Cosa fare
---------

Dunque, se avete un driver per il kernel Linux che non si trova nei sorgenti
principali del kernel, come sviluppatori, cosa dovreste fare?  Rilasciare un
file binario del driver per ogni versione del kernel e per ogni distribuzione,
è un incubo; inoltre, tenere il passo con tutti i cambiamenti del kernel è un
brutto lavoro.

Semplicemente, fate sì che il vostro driver per il kernel venga incluso nei
sorgenti principali (ricordatevi, stiamo parlando di driver rilasciati secondo
una licenza compatibile con la GPL; se il vostro codice non ricade in questa
categoria: buona fortuna, arrangiatevi, siete delle sanguisughe)

Se il vostro driver è nei sorgenti del kernel e un'interfaccia cambia, il
driver verrà corretto immediatamente dalla persona che l'ha modificata.  Questo
garantisce che sia sempre possibile compilare il driver, che funzioni, e tutto
con un minimo sforzo da parte vostra.

Avere il proprio driver nei sorgenti principali del kernel ha i seguenti
vantaggi:

  - La qualità del driver aumenterà e i costi di manutenzione (per lo
    sviluppatore originale) diminuiranno.
  - Altri sviluppatori aggiungeranno nuove funzionalità al vostro driver.
  - Altri persone troveranno e correggeranno bachi nel vostro driver.
  - Altri persone troveranno degli aggiustamenti da fare al vostro driver.
  - Altri persone aggiorneranno il driver quando è richiesto da un cambiamento
    di un'interfaccia.
  - Il driver sarà automaticamente reso disponibile in tutte le distribuzioni
    Linux senza dover chiedere a nessuna di queste di aggiungerlo.

Dato che Linux supporta più dispositivi di qualsiasi altro sistema operativo,
e che girano su molti più tipi di processori di qualsiasi altro sistema
operativo; ciò dimostra che questo modello di sviluppo qualcosa di giusto,
dopo tutto, lo fa :)

------

Dei ringraziamenti vanno a Randy Dunlap, Andrew Morton, David Brownell,
Hanna Linder, Robert Love, e Nishanth Aravamudan per la loro revisione
e per i loro commenti sulle prime bozze di questo articolo.


code:
.. include:: ../disclaimer-ita.rst

:Original: :ref:`Documentation/process/stable-kernel-rules.rst <stable_kernel_rules>`
:Translator: Federico Vaga <federico.vaga@vaga.pv.it>

.. _it_stable_kernel_rules:

Tutto quello che volevate sapere sui rilasci -stable di Linux
==============================================================

Regole sul tipo di patch che vengono o non vengono accettate nei sorgenti
"-stable":

 - Ovviamente dev'essere corretta e verificata.
 - Non dev'essere più grande di 100 righe, incluso il contesto.
 - Deve correggere una cosa sola.
 - Deve correggere un baco vero che sta disturbando gli utenti (non cose del
   tipo "Questo potrebbe essere un problema ...").
 - Deve correggere un problema di compilazione (ma non per cose già segnate
   con CONFIG_BROKEN), un kernel oops, un blocco, una corruzione di dati,
   un vero problema di sicurezza, o problemi del tipo "oh, questo non va bene".
   In pratica, qualcosa di critico.
 - Problemi importanti riportati dagli utenti di una distribuzione potrebbero
   essere considerati se correggono importanti problemi di prestazioni o di
   interattività.  Dato che questi problemi non sono così ovvi e la loro
   correzione ha un'alta probabilità d'introdurre una regressione, dovrebbero
   essere sottomessi solo dal manutentore della distribuzione includendo un
   link, se esiste, ad un rapporto su bugzilla, e informazioni aggiuntive
   sull'impatto che ha sugli utenti.
 - Non deve correggere problemi relativi a una "teorica sezione critica",
   a meno che non venga fornita anche una spiegazione su come questa si
   possa verificare.
 - Non deve includere alcuna correzione "banale" (correzioni grammaticali,
   pulizia dagli spazi bianchi, eccetera).
 - Deve rispettare le regole scritte in
   :ref:`Documentation/translations/it_IT/process/submitting-patches.rst <it_submittingpatches>`
 - Questa patch o una equivalente deve esistere già nei sorgenti principali di
   Linux

Procedura per sottomettere patch per i sorgenti -stable
-------------------------------------------------------

.. note::
  Una patch di sicurezza non dovrebbe essere gestita (solamente) dal processo
  di revisione -stable, ma dovrebbe seguire le procedure descritte in
  :ref:`Documentation/translations/it_IT/admin-guide/security-bugs.rst <it_securitybugs>`.

Per tutte le altre sottomissioni, scegliere una delle seguenti procedure
------------------------------------------------------------------------

.. _it_option_1:

Opzione 1
*********

Per far sì che una patch venga automaticamente inclusa nei sorgenti stabili,
aggiungete l'etichetta

.. code-block:: none

     Cc: stable@vger.kernel.org

nell'area dedicata alla firme. Una volta che la patch è stata inclusa, verrà
applicata anche sui sorgenti stabili senza che l'autore o il manutentore
del sottosistema debba fare qualcosa.

.. _it_option_2:

Opzione 2
*********

Dopo che la patch è stata inclusa nei sorgenti Linux, inviate una mail a
stable@vger.kernel.org includendo: il titolo della patch, l'identificativo
del commit, il perché pensate che debba essere applicata, e in quale versione
del kernel la vorreste vedere.

.. _it_option_3:

Opzione 3
*********

Inviata la patch, dopo aver verificato che rispetta le regole descritte in
precedenza, a stable@vger.kernel.org.  Dovete annotare nel changelog
l'identificativo del commit nei sorgenti principali, così come la versione
del kernel nel quale vorreste vedere la patch.

L':ref:`it_option_1` è fortemente raccomandata; è il modo più facile e usato.
L':ref:`it_option_2` e l':ref:`it_option_3` sono più utili quando, al momento
dell'inclusione dei sorgenti principali, si ritiene che non debbano essere
incluse anche in quelli stabili (per esempio, perché si crede che si dovrebbero
fare più verifiche per eventuali regressioni). L':ref:`it_option_3` è
particolarmente utile se una patch dev'essere riportata su una versione
precedente (per esempio la patch richiede modifiche a causa di cambiamenti di
API).

Notate che per l':ref:`it_option_3`, se la patch è diversa da quella nei
sorgenti principali (per esempio perché è stato necessario un lavoro di
adattamento) allora dev'essere ben documentata e giustificata nella descrizione
della patch.

L'identificativo del commit nei sorgenti principali dev'essere indicato sopra
al messaggio della patch, così:

.. code-block:: none

    commit <sha1> upstream.

In aggiunta, alcune patch inviate attraverso l':ref:`it_option_1` potrebbero
dipendere da altre che devo essere incluse. Questa situazione può essere
indicata nel seguente modo nell'area dedicata alle firme:

.. code-block:: none

     Cc: <stable@vger.kernel.org> # 3.3.x: a1f84a3: sched: Check for idle
     Cc: <stable@vger.kernel.org> # 3.3.x: 1b9508f: sched: Rate-limit newidle
     Cc: <stable@vger.kernel.org> # 3.3.x: fd21073: sched: Fix affinity logic
     Cc: <stable@vger.kernel.org> # 3.3.x
     Signed-off-by: Ingo Molnar <mingo@elte.hu>

La sequenza di etichette ha il seguente significato:

.. code-block:: none

     git cherry-pick a1f84a3
     git cherry-pick 1b9508f
     git cherry-pick fd21073
     git cherry-pick <this commit>

Inoltre, alcune patch potrebbero avere dei requisiti circa la versione del
kernel. Questo può essere indicato usando il seguente formato nell'area
dedicata alle firme:

.. code-block:: none

     Cc: <stable@vger.kernel.org> # 3.3.x

L'etichetta ha il seguente significato:

.. code-block:: none

     git cherry-pick <this commit>

per ogni sorgente "-stable" che inizia con la versione indicata.

Dopo la sottomissione:

 - Il mittente riceverà un ACK quando la patch è stata accettata e messa in
   coda, oppure un NAK se la patch è stata rigettata.  A seconda degli impegni
   degli sviluppatori, questa risposta potrebbe richiedere alcuni giorni.
 - Se accettata, la patch verrà aggiunta alla coda -stable per essere
   revisionata dal altri sviluppatori e dal principale manutentore del
   sottosistema.

Ciclo di una revisione
----------------------

 - Quando i manutentori -stable decidono di fare un ciclo di revisione, le
   patch vengono mandate al comitato per la revisione, ai manutentori soggetti
   alle modifiche delle patch (a meno che il mittente non sia anche il
   manutentore di quell'area del kernel) e in CC: alla lista di discussione
   linux-kernel.
 - La commissione per la revisione ha 48 ore per dare il proprio ACK o NACK
   alle patch.
 - Se una patch viene rigettata da un membro della commissione, o un membro
   della lista linux-kernel obietta la bontà della patch, sollevando problemi
   che i manutentori ed i membri non avevano compreso, allora la patch verrà
   rimossa dalla coda.
 - Le patch che hanno ricevuto un ACK verranno inviate nuovamente come parte di
   un rilascio candidato (-rc) al fine di essere verificate dagli sviluppatori e
   dai testatori.
 - Solitamente si pubblica solo una -rc, tuttavia se si riscontrano problemi
   importanti, alcune patch potrebbero essere modificate o essere scartate,
   oppure nuove patch potrebbero essere messe in coda. Dunque, verranno pubblicate
   nuove -rc e così via finché non si ritiene che non vi siano più problemi.
 - Si può rispondere ad una -rc scrivendo sulla lista di discussione un'email
   con l'etichetta "Tested-by:". Questa etichetta verrà raccolta ed aggiunta al
   commit rilascio.
 - Alla fine del ciclo di revisione il nuovo rilascio -stable conterrà tutte le
   patch che erano in coda e sono state verificate.
 - Le patch di sicurezza verranno accettate nei sorgenti -stable direttamente
   dalla squadra per la sicurezza del kernel, e non passerà per il normale
   ciclo di revisione. Contattate la suddetta squadra per maggiori dettagli
   su questa procedura.

Sorgenti
--------

 - La coda delle patch, sia quelle già applicate che in fase di revisione,
   possono essere trovate al seguente indirizzo:

	https://git.kernel.org/pub/scm/linux/kernel/git/stable/stable-queue.git

 - Il rilascio definitivo, e marchiato, di tutti i kernel stabili può essere
   trovato in rami distinti per versione al seguente indirizzo:

	https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git

 - I rilasci candidati di tutti i kernel stabili possono essere trovati al
   seguente indirizzo:

    https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git/

   .. warning::
     I sorgenti -stable-rc sono un'istantanea dei sorgenti stable-queue e
     subirà frequenti modifiche, dunque verrà anche trapiantato spesso.
     Dovrebbe essere usato solo allo scopo di verifica (per esempio in un
     sistema di CI)

Comitato per la revisione
-------------------------

 - Questo comitato è fatto di sviluppatori del kernel che si sono offerti
   volontari per questo lavoro, e pochi altri che non sono proprio volontari.


code:
.. include:: ../disclaimer-ita.rst

:Original: :ref:`Documentation/process/submit-checklist.rst <submitchecklist>`
:Translator: Federico Vaga <federico.vaga@vaga.pv.it>

.. _it_submitchecklist:

Lista delle verifiche da fare prima di inviare una patch per il kernel Linux
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Qui troverete una lista di cose che uno sviluppatore dovrebbe fare per
vedere le proprie patch accettate più rapidamente.

Tutti questi punti integrano la documentazione fornita riguardo alla
sottomissione delle patch, in particolare
:ref:`Documentation/translations/it_IT/process/submitting-patches.rst <it_submittingpatches>`.

1) Se state usando delle funzionalità del kernel allora includete (#include)
   i file che le dichiarano/definiscono.  Non dipendente dal fatto che un file
   d'intestazione include anche quelli usati da voi.

2) Compilazione pulita:

  a) con le opzioni ``CONFIG`` negli stati ``=y``, ``=m`` e ``=n``. Nessun
     avviso/errore di ``gcc`` e nessun avviso/errore dal linker.

  b) con ``allnoconfig``, ``allmodconfig``

  c) quando si usa ``O=builddir``

  d) Qualsiasi modifica in Documentation/ deve compilare con successo senza
     avvisi o errori. Usare ``make htmldocs`` o ``make pdfdocs`` per verificare
     e correggere i problemi

3) Compilare per diverse architetture di processore usando strumenti per
   la cross-compilazione o altri.

4) Una buona architettura per la verifica della cross-compilazione è la ppc64
   perché tende ad usare ``unsigned long`` per le quantità a 64-bit.

5) Controllate lo stile del codice della vostra patch secondo le direttive
   scritte in :ref:`Documentation/translations/it_IT/process/coding-style.rst <it_codingstyle>`.
   Prima dell'invio della patch, usate il verificatore di stile
   (``script/checkpatch.pl``) per scovare le violazioni più semplici.
   Dovreste essere in grado di giustificare tutte le violazioni rimanenti nella
   vostra patch.

6) Le opzioni ``CONFIG``, nuove o modificate, non scombussolano il menu
   di configurazione e sono preimpostate come disabilitate a meno che non
   soddisfino i criteri descritti in ``Documentation/kbuild/kconfig-language.rst``
   alla punto "Voci di menu: valori predefiniti".

7) Tutte le nuove opzioni ``Kconfig`` hanno un messaggio di aiuto.

8) La patch è stata accuratamente revisionata rispetto alle più importanti
   configurazioni ``Kconfig``.  Questo è molto difficile da fare
   correttamente - un buono lavoro di testa sarà utile.

9) Verificare con sparse.

10) Usare ``make checkstack`` e correggere tutti i problemi rilevati.

    .. note::

       ``checkstack`` non evidenzia esplicitamente i problemi, ma una funzione
       che usa più di 512 byte sullo stack è una buona candidata per una
       correzione.

11) Includete commenti :ref:`kernel-doc <kernel_doc>` per documentare API
    globali del kernel.  Usate ``make htmldocs`` o ``make pdfdocs`` per
    verificare i commenti :ref:`kernel-doc <kernel_doc>` ed eventualmente
    correggerli.

12) La patch è stata verificata con le seguenti opzioni abilitate
    contemporaneamente: ``CONFIG_PREEMPT``, ``CONFIG_DEBUG_PREEMPT``,
    ``CONFIG_DEBUG_SLAB``, ``CONFIG_DEBUG_PAGEALLOC``, ``CONFIG_DEBUG_MUTEXES``,
    ``CONFIG_DEBUG_SPINLOCK``, ``CONFIG_DEBUG_ATOMIC_SLEEP``,
    ``CONFIG_PROVE_RCU`` e ``CONFIG_DEBUG_OBJECTS_RCU_HEAD``.

13) La patch è stata compilata e verificata in esecuzione con, e senza,
    le opzioni ``CONFIG_SMP`` e ``CONFIG_PREEMPT``.

14) Se la patch ha effetti sull'IO dei dischi, eccetera: allora dev'essere
    verificata con, e senza, l'opzione ``CONFIG_LBDAF``.

15) Tutti i percorsi del codice sono stati verificati con tutte le funzionalità
    di lockdep abilitate.

16) Tutti i nuovi elementi in ``/proc`` sono documentati in ``Documentation/``.

17) Tutti i nuovi parametri d'avvio del kernel sono documentati in
    ``Documentation/admin-guide/kernel-parameters.rst``.

18) Tutti i nuovi parametri dei moduli sono documentati con ``MODULE_PARM_DESC()``.

19) Tutte le nuove interfacce verso lo spazio utente sono documentate in
    ``Documentation/ABI/``.  Leggete ``Documentation/ABI/README`` per maggiori
    informazioni.  Le patch che modificano le interfacce utente dovrebbero
    essere inviate in copia anche a linux-api@vger.kernel.org.

20) La patch è stata verificata con l'iniezione di fallimenti in slab e
    nell'allocazione di pagine.  Vedere ``Documentation/fault-injection/``.

    Se il nuovo codice è corposo, potrebbe essere opportuno aggiungere
    l'iniezione di fallimenti specifici per il sottosistema.

21) Il nuovo codice è stato compilato con ``gcc -W`` (usate
    ``make KCFLAGS=-W``).  Questo genererà molti avvisi, ma è ottimo
    per scovare bachi come  "warning: comparison between signed and unsigned".

22) La patch è stata verificata dopo essere stata inclusa nella serie di patch
    -mm; questo al fine di assicurarsi che continui a funzionare assieme a
    tutte le altre patch in coda e i vari cambiamenti nei sottosistemi VM, VFS
    e altri.

23) Tutte le barriere di sincronizzazione {per esempio, ``barrier()``,
    ``rmb()``, ``wmb()``} devono essere accompagnate da un commento nei
    sorgenti che ne spieghi la logica: cosa fanno e perché.

24) Se la patch aggiunge nuove chiamate ioctl, allora aggiornate
    ``Documentation/userspace-api/ioctl/ioctl-number.rst``.

25) Se il codice che avete modificato dipende o usa una qualsiasi interfaccia o
    funzionalità del kernel che è associata a uno dei seguenti simboli
    ``Kconfig``, allora verificate che il kernel compili con diverse
    configurazioni dove i simboli sono disabilitati e/o ``=m`` (se c'è la
    possibilità) [non tutti contemporaneamente, solo diverse combinazioni
    casuali]:

    ``CONFIG_SMP``, ``CONFIG_SYSFS``, ``CONFIG_PROC_FS``, ``CONFIG_INPUT``,
    ``CONFIG_PCI``, ``CONFIG_BLOCK``, ``CONFIG_PM``, ``CONFIG_MAGIC_SYSRQ``,
    ``CONFIG_NET``, ``CONFIG_INET=n`` (ma l'ultimo con ``CONFIG_NET=y``).