From nobody Mon Feb 9 20:36:22 2026 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 6ED08C6FD1F for ; Sun, 19 Mar 2023 13:46:53 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230259AbjCSNqw (ORCPT ); Sun, 19 Mar 2023 09:46:52 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:48252 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229508AbjCSNqt (ORCPT ); Sun, 19 Mar 2023 09:46:49 -0400 Received: from mx.kolabnow.com (mx.kolabnow.com [212.103.80.153]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 4C5581F5F9; Sun, 19 Mar 2023 06:46:43 -0700 (PDT) Received: from localhost (unknown [127.0.0.1]) by mx.kolabnow.com (Postfix) with ESMTP id 9953C1E9C; Sun, 19 Mar 2023 14:46:40 +0100 (CET) Authentication-Results: ext-mx-out001.mykolab.com (amavisd-new); dkim=pass (4096-bit key) reason="pass (just generated, assumed good)" header.d=kolabnow.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kolabnow.com; h= content-transfer-encoding:content-type:content-type:mime-version :message-id:date:date:subject:subject:from:from:received :received:received; s=dkim20160331; t=1679233597; x=1681047998; bh=+ZIgmGE/D2T5FWuLp7AB3aaPwq39dKzqTojxmTeieVQ=; b=P2fya+1R6+t3 odATf11Mjwq7KfRdZn4IkiY2TY5MPpa5ka4O0DzTRqwyMVpc+HzsiBNQOp/+J57G F2R1vyv687sqQlxUUuQhV2uMb9/I2PHSmiidQpxLS367TaD7g6W5nIQRDqpws1Eh dRyyLfdUHHAvMQi+YPeittGiEmrFZQIRMWsidfZkGBTVSMDOHSWfmD6/2qYB/EQ9 yETQds8lYCrVLo9MNvY9Stfyh8/dbvp+1z+mJ9e63eCLP0TaifhAxcR2QQDtQYnk 2JBTagB02vgnV5C3m3K386L3LlpkiZ2UvT1voKiMlFVz0eFUo/GkYdHd2qTNTVge U2ueUGbfWoPjHN7mMFwampN8iMVBEOtF+y0RE0GJoGphIv0Ap4vOjV1q8TeWPEHB 93NWDrBD0JE0Z2dHujvbFjgBDj3Zw7nkEymEyrHFriQK61S3j6OMc60TDq8pk0y0 5U13M+K6HXSpHkcbPnjWNVCvnKpJURU2Lre4311CSEcUoVJgRCC7Mmg/ULbVXHht Pek3jzXq2YXJqiJ7fov0Cx0Rq2wgwaNSItsn8yGnBMgyJpWHUSCJgBYK/XNitfLp aS7pkoHq76v8brQzdcTPHP8kdsthezeqXmck/ceiN1mnTbGy/iAhNJvZFLdlIYCq KUTNP90WXx7ltfF9ZJZ1kS6kRRjDlao= X-Virus-Scanned: amavisd-new at mykolab.com Received: from mx.kolabnow.com ([127.0.0.1]) by localhost (ext-mx-out001.mykolab.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5pBl4XEnKVFc; Sun, 19 Mar 2023 14:46:37 +0100 (CET) Received: from int-mx001.mykolab.com (unknown [10.9.13.1]) by mx.kolabnow.com (Postfix) with ESMTPS id 2C9521E42; Sun, 19 Mar 2023 14:46:36 +0100 (CET) Received: from ext-subm003.mykolab.com (unknown [10.9.6.3]) by int-mx001.mykolab.com (Postfix) with ESMTPS id 2B84F123F; Sun, 19 Mar 2023 14:46:36 +0100 (CET) From: Federico Vaga To: Jonathan Corbet Cc: linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org, Federico Vaga Subject: [PATCH] doc:it_IT: translation alignment Date: Sun, 19 Mar 2023 14:46:24 +0100 Message-Id: <20230319134624.21327-1-federico.vaga@vaga.pv.it> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Major update for maintainer-pgp-guide commit e4412739472b ("Documentation: raise minimum supported version of bin= utils to 2.25") commit 67fe6792a7fb ("Documentation: stable: Document alternative for refer= ring upstream commit hash") commit 8763a30bc15b ("docs: deprecated.rst: Add note about DECLARE_FLEX_ARR= AY() usage commit 2f993509a97e ("docs: process/5.Posting.rst: clarify use of Reported-= by: tag") commit a31323bef2b6 ("timers: Update the documentation to reflect on the ne= w timer_shutdown() API") Signed-off-by: Federico Vaga --- .../it_IT/kernel-hacking/locking.rst | 5 + .../translations/it_IT/process/5.Posting.rst | 6 +- .../translations/it_IT/process/changes.rst | 4 +- .../translations/it_IT/process/deprecated.rst | 29 +- .../it_IT/process/maintainer-pgp-guide.rst | 346 +++++++++--------- .../it_IT/process/stable-kernel-rules.rst | 6 + 6 files changed, 214 insertions(+), 182 deletions(-) diff --git a/Documentation/translations/it_IT/kernel-hacking/locking.rst b/= Documentation/translations/it_IT/kernel-hacking/locking.rst index 05d362b16bf0..a9e781d2e323 100644 --- a/Documentation/translations/it_IT/kernel-hacking/locking.rst +++ b/Documentation/translations/it_IT/kernel-hacking/locking.rst @@ -1029,6 +1029,11 @@ Dato che questo =C3=A8 un problema abbastanza comune= con una propensione alle corse critiche, dovreste usare timer_delete_sync() (``include/linux/timer.h``) per gestire questo caso. =20 +Prima di rilasciare un temporizzatore dovreste chiamare la funzione +timer_shutdown() o timer_shutdown_sync() di modo che non venga pi=C3=B9 ri= carmato. +Ogni successivo tentativo di riarmare il temporizzatore verr=C3=A0 silenzi= osamente +ignorato. + Velocit=C3=A0 della sincronizzazione =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D =20 diff --git a/Documentation/translations/it_IT/process/5.Posting.rst b/Docum= entation/translations/it_IT/process/5.Posting.rst index cf92a16ed7e5..f61059c8ac8d 100644 --- a/Documentation/translations/it_IT/process/5.Posting.rst +++ b/Documentation/translations/it_IT/process/5.Posting.rst @@ -272,8 +272,10 @@ Le etichette in uso pi=C3=B9 comuni sono: - Cc: la persona menzionata ha ricevuto una copia della patch ed ha avuto l'opportunit=C3=A0 di commentarla. =20 -State attenti ad aggiungere queste etichette alla vostra patch: solo -"Cc:" pu=C3=B2 essere aggiunta senza il permesso esplicito della persona m= enzionata. +State attenti ad aggiungere queste etichette alla vostra patch: solo "Cc:"= pu=C3=B2 +essere aggiunta senza il permesso esplicito della persona menzionata. Il p= i=C3=B9 +delle volte anche Reported-by: va bene, ma =C3=A8 sempre meglio chiedere s= pecialmente +se il baco =C3=A8 stato riportato in una comunicazione privata. =20 Inviare la modifica ------------------- diff --git a/Documentation/translations/it_IT/process/changes.rst b/Documen= tation/translations/it_IT/process/changes.rst index 473ec2cc558e..f37c53f8b524 100644 --- a/Documentation/translations/it_IT/process/changes.rst +++ b/Documentation/translations/it_IT/process/changes.rst @@ -36,7 +36,7 @@ GNU C 5.1 gcc --version Clang/LLVM (optional) 11.0.0 clang --version GNU make 3.81 make --version bash 4.2 bash --version -binutils 2.23 ld -v +binutils 2.25 ld -v flex 2.5.35 flex --version bison 2.0 bison --version pahole 1.16 pahole --version @@ -97,7 +97,7 @@ Questo richiede bash 4.2 o successivo. Binutils -------- =20 -Per generare il kernel =C3=A8 necessario avere Binutils 2.23 o superiore. +Per generare il kernel =C3=A8 necessario avere Binutils 2.25 o superiore. =20 pkg-config ---------- diff --git a/Documentation/translations/it_IT/process/deprecated.rst b/Docu= mentation/translations/it_IT/process/deprecated.rst index febf83897783..57b501f0dfa4 100644 --- a/Documentation/translations/it_IT/process/deprecated.rst +++ b/Documentation/translations/it_IT/process/deprecated.rst @@ -332,7 +332,7 @@ zero come risultato:: =20 Il valore di ``size`` nell'ultima riga sar=C3=A0 ``zero``, quando uno invece si aspetterebbe che il suo valore sia la dimensione totale in -byte dell'allocazione dynamica che abbiamo appena fatto per l'array +byte dell'allocazione dinamica che abbiamo appena fatto per l'array ``items``. Qui un paio di esempi reali del problema: `collegamento 1 `_, `collegamento 2 @@ -381,4 +381,29 @@ combinazione con struct_size() e flex_array_size():: instance =3D kmalloc(struct_size(instance, items, count), GFP_KERN= EL); instance->count =3D count; =20 - memcpy(instance->items, source, flex_array_size(instance, items, instance= ->count)); + memcpy(instance->items, source, flex_array_size(instance, items, i= nstance->count)); + +Ci sono due casi speciali dove =C3=A8 necessario usare la macro DECLARE_FL= EX_ARRAY() +(da notare che la stessa macro =C3=A8 chiamata __DECLARE_FLEX_ARRAY() nei = file di +intestazione UAPI). Uno =C3=A8 quando l'array flessibile =C3=A8 l'unico el= emento di una +struttura, e l'altro =C3=A8 quando =C3=A8 parti un unione. Per motivi non = tecnici, entrambi +i casi d'uso non sono permessi dalla specifica C99. Per esempio, per +convertire il seguente codice:: + + struct something { + ... + union { + struct type1 one[0]; + struct type2 two[0]; + }; + }; + +La macro di supporto dev'essere usata:: + + struct something { + ... + union { + DECLARE_FLEX_ARRAY(struct type1, one); + DECLARE_FLEX_ARRAY(struct type2, two); + }; + }; diff --git a/Documentation/translations/it_IT/process/maintainer-pgp-guide.= rst b/Documentation/translations/it_IT/process/maintainer-pgp-guide.rst index 5526bcabeb0a..e5c2a3a4d364 100644 --- a/Documentation/translations/it_IT/process/maintainer-pgp-guide.rst +++ b/Documentation/translations/it_IT/process/maintainer-pgp-guide.rst @@ -68,42 +68,24 @@ stesso. Strumenti PGP =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D =20 -Usare GnuPG v2 --------------- +Usare GnuPG 2.2 o successivo +---------------------------- =20 La vostra distribuzione potrebbe avere gi=C3=A0 installato GnuPG, dovete s= olo -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:: +verificare che stia utilizzando la versione abbastanza recente. Per contro= llate +usate:: =20 $ gpg --version | head -n1 =20 -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 vers= ione, -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 c= reare -un alias:: - - $ alias gpg=3Dgpg2 - -Potete mettere questa opzione nel vostro ``.bashrc`` in modo da essere si= curi. +Se state utilizzando la version 2.2 o successiva, allora siete pronti a pa= rtire. +Se invece state usando una versione precedente, allora alcuni comandi elen= cati +in questa guida potrebbero non funzionare. =20 Configurare le opzioni di gpg-agent ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ =20 L'agente GnuPG =C3=A8 uno strumento di aiuto che partir=C3=A0 automaticame= nte ogni volta -che userete il comando ``gpg`` e funzioner=C3=A0 in background con l'obiet= tivo di +che userete il comando ``gpg`` e funzioner=C3=A0 in *background* con l'obi= ettivo di individuare la passphrase. Ci sono due opzioni che dovreste conoscere per personalizzare la scadenza della passphrase nella cache: =20 @@ -131,19 +113,7 @@ valori:: riguarda vecchie le versioni di GnuPG, poich=C3=A9 potrebbero non svol= gere pi=C3=B9 bene il loro compito. =20 -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 =C3=A8 sv= olto -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 u= sate -il comando ``gpg2`` se per voi ``gpg`` corrisponde alla versione GnuPG v.1. - -.. _it_master_key: +.. _it_protect_your_key: =20 Proteggere la vostra chiave PGP primaria =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D @@ -155,55 +125,62 @@ al documento "`Protecting Code Integrity`_" che abbia= mo menzionato prima. Dovreste inoltre creare una nuova chiave se quella attuale =C3=A8 inferior= e a 2048 bit (RSA). =20 -Chiave principale o sottochiavi -------------------------------- - -Le sottochiavi sono chiavi PGP totalmente indipendenti, e sono collegate a= lla -chiave principale attraverso firme certificate. =C3=88 quindi importante -comprendere i seguenti punti: - -1. Non ci sono differenze tecniche tra la chiave principale e la sottochia= ve. -2. In fase di creazione, assegniamo limitazioni funzionali ad ogni chiave - assegnando capacit=C3=A0 specifiche. -3. Una chiave PGP pu=C3=B2 avere 4 capacit=C3=A0: +Le sottochiavi PGP +------------------ =20 - - **[S]** pu=C3=B2 essere usata per firmare - - **[E]** pu=C3=B2 essere usata per criptare - - **[A]** pu=C3=B2 essere usata per autenticare - - **[C]** pu=C3=B2 essere usata per certificare altre chiavi +Raramente le chiavi PGP sono composte da una singola coppia -- solitamente= , sono +una collezione di sottochiavi indipendenti usate per diversi scopi in funz= ione +delle capacit=C3=A0 assegnate al momento della creazione. Una chiave PGP p= u=C3=B2 avere +quattro capacit=C3=A0: + +- **[S]** pu=C3=B2 essere usata per firmare +- **[E]** pu=C3=B2 essere usata per criptare +- **[A]** pu=C3=B2 essere usata per autenticare +- **[C]** pu=C3=B2 essere usata per certificare altre chiavi + +La chiave con la capacit=C3=A0 **[C]** viene spesso chiamata chiave "passe= partout" +(*master key*), ma =C3=A8 una terminologia fuorviante perch=C3=A9 lascia i= ntendere che la +chiave di certificato possa essere usate in sostituzione delle altre (prop= rio +come le vere chiavi passpartout in grado di aprire diverse serrature). Dat= o che +questo non =C3=A8 il caso, per evitare fraintendimenti, in questa guida ci= riferiremo +a questa chiave chiamandola "La chiave di certificazione". + +I seguenti punti sono molto importanti: + +1. Tutte le sottochiavi sono indipendenti. Se perdete una sottochiave priv= ata + non potrete recuperarla usando le altre. +2. Ad eccezione della chiave di certificazione, ci possono essere pi=C3=B9 + sottochiavi con le stesse capacit=C3=A0 (per esempio, potete avere 2 so= ttochiavi + per criptare, 3 per firmare, ma solo una per una sola per certificare).= Tutte + le sottochiavi sono indipendenti -- un messaggio criptato usando una ch= iave + **[E]** non pu=C3=B2 essere decriptato usano altre sottochiavi **[E]**. +3. Una sottochiave pu=C3=B2 avere pi=C3=B9 capacit=C3=A0 (per esempio, la = chiave **[C]** pu=C3=B2 + anche essere una chiave **[S]**). + +La chiave con capacit=C3=A0 **[C]** (certificazione) =C3=A8 la sola che pu= =C3=B2 essere usata +per indicare relazioni fra chiavi. Solo la chiave **[C]** pu=C3=B2 essere = usata per: + +- aggiungere o revocare altre chiavi (sottochiavi) che hanno capacit=C3=A0= S/E/A; +- aggiungere, modificare o eliminare le identit=C3=A0 (unids) associate al= la chiave; +- aggiungere o modificare la propria data di scadenza o delle sottochiavi; +- firmare le chiavi di altre persone a scopo di creare una rete di fiducia. =20 -4. Una singola chiave pu=C3=B2 avere pi=C3=B9 capacit=C3=A0 -5. Una sottochiave =C3=A8 completamente indipendente dalla chiave principa= le. - Un messaggio criptato con la sottochiave non pu=C3=B2 essere decrittato= con - quella principale. Se perdete la vostra sottochiave privata, non pu=C3= =B2 - essere rigenerata in nessun modo da quella principale. +Di base, alla creazione di nuove chiavi, GnuPG genera quanto segue: =20 -La chiave con capacit=C3=A0 **[C]** (certify) =C3=A8 identificata come la = chiave -principale perch=C3=A9 =C3=A8 l'unica che pu=C3=B2 essere usata per indica= re la relazione -con altre chiavi. Solo la chiave **[C]** pu=C3=B2 essere usata per: +- Una chiave la capacit=C3=A0 di certificazione che quella di firma (**[SC= ]**) +- Una sottochiave separata con capacit=C3=A0 di criptare (**[E]**) =20 -- Aggiungere o revocare altre chiavi (sottochiavi) che hanno capacit=C3=A0= S/E/A -- Aggiungere, modificare o eliminare le identit=C3=A0 (unids) associate al= la chiave -- Aggiungere o modificare la data di termine di s=C3=A9 stessa o di ogni s= ottochiave -- Firmare le chiavi di altre persone a scopo di creare una rete di fiducia =20 -Di base, alla creazione di nuove chiavi, GnuPG genera quanto segue: =20 -- Una chiave madre che porta sia la capacit=C3=A0 di certificazione che qu= ella - di firma (**[SC]**) -- Una sottochiave separata con capacit=C3=A0 di criptaggio (**[E]**) =20 -Se avete usato i parametri di base per generare la vostra chiave, quello +Se avete usato i parametri predefiniti per generare la vostra chiave, quel= lo sar=C3=A0 il risultato. Potete verificarlo utilizzando ``gpg --list-secret= -keys``, per esempio:: =20 - sec rsa2048 2018-01-23 [SC] [expires: 2020-01-23] + sec ed25519 2022-12-20 [SC] [expires: 2024-12-19] 000000000000000000000000AAAABBBBCCCCDDDD uid [ultimate] Alice Dev - ssb rsa2048 2018-01-23 [E] [expires: 2020-01-23] - -Qualsiasi chiave che abbia la capacit=C3=A0 **[C]** =C3=A8 la vostra chiav= e madre, -indipendentemente da quali altre capacit=C3=A0 potreste averle assegnato. + ssb cv25519 2022-12-20 [E] [expires: 2024-12-19] =20 La lunga riga sotto la voce ``sec`` =C3=A8 la vostra impronta digitale -- negli esempi che seguono, quando vedere ``[fpr]`` ci si riferisce a questa @@ -238,20 +215,10 @@ possano ricevere la vostra nuova sottochiave:: $ gpg --send-key [fpr] =20 .. note:: Supporto ECC in GnuPG - GnuPG 2.1 e successivi supportano pienamente *Elliptic Curve Cryptogra= phy*, - con la possibilit=C3=A0 di combinare sottochiavi ECC con le tradiziona= li chiavi - primarie RSA. Il principale vantaggio della crittografia ECC =C3=A8 ch= e =C3=A8 molto - pi=C3=B9 veloce da calcolare e crea firme pi=C3=B9 piccole se confront= ate byte per - byte con le chiavi RSA a pi=C3=B9 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 com= ando - 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". + + Tenete presente che se avete intenzione di usare un dispositivo che non + supporta chiavi ED25519 ECC, allora dovreste usare "nistp256" al posto = di + "ed25519". Pi=C3=B9 avanti ci sono alcune raccomandazioni per i disposi= tivi. =20 Copia di riserva della chiave primaria per gestire il recupero da disastro -------------------------------------------------------------------------- @@ -360,13 +327,13 @@ Per prima cosa, identificate il keygrip della vostra = chiave primaria:: =20 L'output assomiglier=C3=A0 a questo:: =20 - pub rsa2048 2018-01-24 [SC] [expires: 2020-01-24] + pub ed25519 2022-12-20 [SC] [expires: 2022-12-19] 000000000000000000000000AAAABBBBCCCCDDDD Keygrip =3D 1111000000000000000000000000000000000000 uid [ultimate] Alice Dev - sub rsa2048 2018-01-24 [E] [expires: 2020-01-24] + sub cv25519 2022-12-20 [E] [expires: 2022-12-19] Keygrip =3D 2222000000000000000000000000000000000000 - sub ed25519 2018-01-24 [S] + sub ed25519 2022-12-20 [S] Keygrip =3D 3333000000000000000000000000000000000000 =20 Trovate la voce keygrid che si trova sotto alla riga ``pub`` (appena sotto @@ -389,11 +356,11 @@ Ora, se eseguite il comando ``--list-secret-keys``, v= edrete che la chiave primaria non compare pi=C3=B9 (il simbolo ``#`` indica che non =C3=A8 disp= onibile):: =20 $ gpg --list-secret-keys - sec# rsa2048 2018-01-24 [SC] [expires: 2020-01-24] + sec# ed25519 2022-12-20 [SC] [expires: 2024-12-19] 000000000000000000000000AAAABBBBCCCCDDDD uid [ultimate] Alice Dev - ssb rsa2048 2018-01-24 [E] [expires: 2020-01-24] - ssb ed25519 2018-01-24 [S] + ssb cv25519 2022-12-20 [E] [expires: 2024-12-19] + ssb ed25519 2022-12-20 [S] =20 Dovreste rimuovere anche i file ``secring.gpg`` che si trovano nella carte= lla ``~/.gnupg``, in quanto rimasugli delle versioni precedenti di GnuPG. @@ -461,18 +428,20 @@ soluzioni disponibili: computer portatili pi=C3=B9 recenti. In aggiunta, offre altre funzionali= t=C3=A0 di sicurezza come FIDO, U2F, e ora supporta anche le chiavi ECC (NISTP) =20 -`Su LWN c'=C3=A8 una buona recensione`_ dei modelli elencati qui sopra e a= ltri. -La scelta dipender=C3=A0 dal costo, dalla disponibilit=C3=A0 nella vostra = area -geografica e vostre considerazioni sull'hardware aperto/proprietario. +La vostra scelta dipender=C3=A0 dal costo, la disponibilit=C3=A0 nella vos= tra regione, e +sulla scelta fra dispositivi aperti e proprietari. =20 -Se volete usare chiavi ECC, la vostra migliore scelta sul mercato =C3=A8 la -Nitrokey Start. +.. note:: + + Se siete nella lista MAINTAINERS o avete un profilo su kernel.org, all= ora + `potrete avere gratuitamente una Nitrokey Start`_ grazie alla fondazio= ne + Linux. =20 .. _`Nitrokey Start`: https://shop.nitrokey.com/shop/product/nitrokey-star= t-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'=C3=A8 una buona recensione`: https://lwn.net/Articles/73623= 1/ +.. _`potrete avere gratuitamente una Nitrokey Start`: https://www.kernel.o= rg/nitrokey-digital-tokens-for-kernel-developers.html =20 Configurare il vostro dispositivo smartcard ------------------------------------------- @@ -513,6 +482,12 @@ altre informazioni sulla carta che potrebbero trapelar= e in caso di smarrimento. A dispetto del nome "PIN", n=C3=A9 il PIN utente n=C3=A9 quello dell'a= mministratore devono essere esclusivamente numerici. =20 +.. warning:: + + Alcuni dispositivi richiedono la presenza delle sottochiavi nel dispos= itivo + stesso prima che possiate cambiare la passphare. Verificate la + documentazione del produttore. + Spostare le sottochiavi sulla smartcard --------------------------------------- =20 @@ -525,11 +500,11 @@ dell'amministratore:: =20 Secret subkeys are available. =20 - pub rsa2048/AAAABBBBCCCCDDDD - created: 2018-01-23 expires: 2020-01-23 usage: SC + pub ed25519/AAAABBBBCCCCDDDD + created: 2022-12-20 expires: 2024-12-19 usage: SC trust: ultimate validity: ultimate - ssb rsa2048/1111222233334444 - created: 2018-01-23 expires: never usage: E + ssb cv25519/1111222233334444 + created: 2022-12-20 expires: never usage: E ssb ed25519/5555666677778888 created: 2017-12-07 expires: never usage: S [ultimate] (1). Alice Dev @@ -594,11 +569,11 @@ Ora, se doveste usare l'opzione ``--list-secret-keys`= `, vedrete una sottile differenza nell'output:: =20 $ gpg --list-secret-keys - sec# rsa2048 2018-01-24 [SC] [expires: 2020-01-24] + sec# ed25519 2022-12-20 [SC] [expires: 2024-12-19] 000000000000000000000000AAAABBBBCCCCDDDD uid [ultimate] Alice Dev - ssb> rsa2048 2018-01-24 [E] [expires: 2020-01-24] - ssb> ed25519 2018-01-24 [S] + ssb> cv25519 2022-12-20 [E] [expires: 2024-12-19] + ssb> ed25519 2022-12-20 [S] =20 Il simbolo ``>`` in ``ssb>`` indica che la sottochiave =C3=A8 disponibile = solo nella smartcard. Se tornate nella vostra cartella delle chiavi segrete e @@ -661,7 +636,7 @@ eseguite:: Se per voi =C3=A8 pi=C3=B9 facile da memorizzare, potete anche utilizzare = una data specifica (per esempio, il vostro compleanno o capodanno):: =20 - $ gpg --quick-set-expire [fpr] 2020-07-01 + $ gpg --quick-set-expire [fpr] 2025-07-01 =20 Ricordatevi di inviare l'aggiornamento ai keyserver:: =20 @@ -676,6 +651,21 @@ dovreste importarle nella vostra cartella di lavoro ab= ituale:: $ gpg --export | gpg --homedir ~/.gnupg --import $ unset GNUPGHOME =20 +Usare gpg-agent con ssh +~~~~~~~~~~~~~~~~~~~~~~~ + +Se dovete firmare tag o commit su un sistema remoto, potete ridirezionare = il +vostro gpg-agent attraverso ssh. Consultate le istruzioni disponibili nell= a wiki +GnuPG: + +- `Agent Forwarding over SSH`_ + +Funziona senza troppi intoppi se avete la possibilit=C3=A0 di modificare le +impostazioni di sshd sul sistema remoto. + +.. _`Agent Forwarding over SSH`: https://wiki.gnupg.org/AgentForwarding + +.. _it_pgp_with_git: =20 Usare PGP con Git =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D @@ -709,11 +699,6 @@ avere pi=C3=B9 chiavi segrete, potete dire a git quale= dovrebbe usare (``[fpg]`` =20 $ git config --global user.signingKey [fpr] =20 -**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 ------------------ =20 @@ -812,6 +797,61 @@ Potete dire a git di firmare sempre i commit:: =20 .. _it_verify_identities: =20 +Come lavorare con patch firmate +------------------------------- + +Esiste la possibilit=C3=A0 di usare la vostra chiave PGP per firmare le pa= tch che +invierete alla liste di discussione del kernel. I meccanismi esistenti per= la +firma delle email (PGP-Mime o PGP-inline) tendono a causare problemi +nell'attivit=C3=A0 di revisione del codice. Si suggerisce, invece, di util= izare lo +strumento sviluppato da kernel.org che mette nell'intestazione del messagg= io +un'attestazione delle firme crittografiche (tipo DKIM): + +- `Patatt Patch Attestation`_ + +.. _`Patatt Patch Attestation`: https://pypi.org/project/patatt/ + +Installare e configurate patatt +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +Lo strumento patatt =C3=A8 disponibile per diverse distribuzioni, dunque c= ercatelo +prima l=C3=AC. Oppure potete installarlo usano pypi "``pip install patatt`= `" + +Se avete gi=C3=A0 configurato git con la vostra chiave PGP (usando +``user.signingKey``), allora patatt non ha bisogno di alcuna configurazione +aggiuntiva. Potete iniziare a firmare le vostre patch aggiungendo un aggan= cio a +git-send-email nel vostro repositorio:: + + patatt install-hook + +Ora, qualsiasi patch che invierete con ``git send-email`` verr=C3=A0 autom= aticamente +firmata usando la vostra firma crittografica. + +Verificare le firme di patatt +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +Se usate ``b4`` per verificare ed applicare le patch, allora tenter=C3=A0 +automaticamente di verificare tutte le firme DKIM e patatt disponibili. Per +esempio:: + + $ b4 am 20220720205013.890942-1-broonie@kernel.org + [...] + Checking attestation on all messages, may take a moment... + --- + =E2=9C=93 [PATCH v1 1/3] kselftest/arm64: Correct buffer allocation = for SVE Z registers + =E2=9C=93 [PATCH v1 2/3] arm64/sve: Document our actual ABI for clea= ring registers on syscall + =E2=9C=93 [PATCH v1 3/3] kselftest/arm64: Enforce actual ABI for SVE= syscalls + --- + =E2=9C=93 Signed: openpgp/broonie@kernel.org + =E2=9C=93 Signed: DKIM/kernel.org + +.. note:: + + Lo sviluppo di patatt e b4 =C3=A8 piuttosto attivo. Si consiglia di ver= ificare la + documentazione pi=C3=B9 recente. + +.. _it_kernel_identities: + Come verificare l'identit=C3=A0 degli sviluppatori del kernel =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D =20 @@ -884,64 +924,18 @@ di base di GnuPG v2). Per farlo, aggiungete (o modifi= cate) l'impostazione =20 trust-model tofu+pgp =20 -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. =C3= =88 -importante tenere bene a mente che non c'=C3=A8 alcuna garanzia che la chi= ave -che avete recuperato da un keyserver PGP appartenga davvero alla persona -reale -- =C3=A8 progettato cos=C3=AC. Dovreste usare il Web of Trust per a= ssicurarvi -che la chiave sia valida. - -Come mantenere il Web of Trust va oltre gli scopi di questo documento, -semplicemente perch=C3=A9 farlo come si deve richiede sia sforzi che perse= veranza -che tendono ad andare oltre al livello di interesse della maggior parte de= gli -esseri umani. Qui di seguito alcuni rapidi suggerimenti per aiutarvi a rid= urre -il rischio di importare chiavi maligne. - -Primo, diciamo che avete provato ad eseguire ``git verify-tag`` ma restitu= isce -un errore dicendo che la chiave non =C3=A8 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 DA73759BF8619E484E5A3B47389A54219C0F= 2430 - 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 - 4096 bit RSA key C94035C21B4F2AEB, created: 2017-03-14, expires:= 2019-03-15 - Keys 1-1 of 1 for "DA73759BF8619E484E5A3B47389A54219C0F2430". Enter n= umber(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 - 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 =C3=A8 un buon segno circa la va= lidit=C3=A0 -della chiave. Ora, potete aggiungerla al vostro portachiavi dal keyserver:: - - $ gpg --recv-key C94035C21B4F2AEB - -Questa procedura non =C3=A8 perfetta, e ovviamente state riponendo la vost= ra -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=C3=A0 un dec= iso -miglioramento rispetto alla cieca fiducia nei keyserver. +Usare il repositorio kernel.org per il web of trust +--------------------------------------------------- + +Il progetto kernel.org mantiene un repositorio git con le chiavi pubbliche= degli sviluppatori in alternativa alla replica dei server di chiavi che ne= gli ultimi anni sono spariti. La documentazione completa su come impostare = il repositorio come vostra sorgente di chiavi pubbliche pu=C3=B2 essere tro= vato qui: + +- `Kernel developer PGP Keyring`_ + +Se siete uno sviluppatore del kernel, per favore valutate l'idea di inviar= e la +vostra chiave per l'inclusione in quel portachiavi. + + +If you are a kernel developer, please consider submitting your key for +inclusion into that keyring. + +.. _`Kernel developer PGP Keyring`: https://korg.docs.kernel.org/pgpkeys.h= tml diff --git a/Documentation/translations/it_IT/process/stable-kernel-rules.r= st b/Documentation/translations/it_IT/process/stable-kernel-rules.rst index 0be675b03199..248bf1e4b171 100644 --- a/Documentation/translations/it_IT/process/stable-kernel-rules.rst +++ b/Documentation/translations/it_IT/process/stable-kernel-rules.rst @@ -106,6 +106,12 @@ al messaggio della patch, cos=C3=AC: =20 commit upstream. =20 +o in alternativa: + +.. code-block:: none + + [ Upstream commit ] + In aggiunta, alcune patch inviate attraverso l':ref:`it_option_1` potrebbe= ro dipendere da altre che devo essere incluse. Questa situazione pu=C3=B2 ess= ere indicata nel seguente modo nell'area dedicata alle firme: --=20 2.30.2