Soluzione al problema deprecamento apt-key

[xavier77]

Prima che arrivino segnalazioni, posto questo articolo:
https://www.marcosbox.org/2022/07/ubunt ... ey-is.html
All'inizio mi ero allertato perché sembrava che i PPA fossero esenti dal problema. Adesso invece, dopo aver riletto, sembra che sia un "falso problema".
Prima di tutto perché la chiave è già in gpg (se fosse stata in asc sarebbe stato un altro discorso...).
Il problema potrebbe essere semmai che la chiave risieda in etc/apt/trusted.gpg.d (come si evince anche dall'output).

Alla fine per farla breve, ho fatto un semplice test: su 22.04 ho aggiunto gli stessi PPA (quelli di LibreOffice) e ho aggiornato apt.
Nessun errore.

Per quello che posso dire finora, per i PPA non c'è bisogno di procedure diverse da quelle classiche.
Ovviamente se così non fosse e volete fare segnalazioni, quest'ultime sono sempre gradite.

[wilecoyote]

) Salve, uhm, non ho fatto prove dirette nei miei Jammy 22.04 LTS, però in giro installazioni coi ppa già l'ho viste, ed il apt-key non ha dato segni di vita.

Al momento non c'è segnale alcuno che possa dare problemi.

:: Ciao

[xavier77]

Allora facciamo un po' il punto della situazione.
È stato pubblicato un articolo che spiega bene cosa è cambiato:
https://itsfoss.com/apt-key-deprecated/
Non è l'unico chiaramente, ma mi sembra quello più completo ed esaustivo letto di recente.
Ne ho tratto anche spunto per una piccola rettifica alla guida (gli avvisi su apt-key tecnicamente non sono messaggi di errore ma avvertimenti).

Per quel che questa faccenda comporta sulla gestione del wiki, di seguito lascio alcuni spunti di riflessione da cui partirei nel futuro (anche non immediato).
NB: nulla di urgente, soltanto degli aspetti su cui riflettere, per eventualmente ripensare le soluzioni che abbiamo finora adottato.

• Purtroppo con la nuova procedura bisogna usare il terminale (e anche la testa, un minimo). Per gli utenti avanzati cambia poco. Per gli utenti occasionali/noob/poco esperti ecc. cambia molto, perché non c'è più l'immediatezza del "clicca sul file deb e fine".
• Molto dipende da manutentori dei repository esterni. Esempi a caso: brave browser si è adeguato, Virtualbox pure, Spotify no, come anche (mi pare) Vivaldi e TeamViewer. Questa è una grande scocciatura.
• Un grande dubbio: dal deprecamento di apt-key le chiavi non devono stare in trusted.gpg. Il sistema "non si lamenta" se vengono messe altrove (in trusted.gpg.d, in /etc/apt/keyrings/ o anche nella Home per chi vuole). Tuttavia noto che tutti i programmi di terze parti che si sono adeguati (vedi punto precedente) le fanno mettere in /usr/share/keyrings/; che è la destinazione indicata dalla policy Debian (come feci notare anche a suo tempo). Invece da due mesi scriviamo nel wiki di salvarle in /etc/apt/keyrings.

[frapox]

Un grande dubbio:[/u][/b] dal deprecamento di apt-key le chiavi non devono stare in trusted.gpg. Il sistema "non si lamenta" se vengono messe altrove (in trusted.gpg.d, in /etc/apt/keyrings/ o anche nella Home per chi vuole). Tuttavia noto che tutti i programmi di terze parti che si sono adeguati (vedi punto precedente) le fanno mettere in /usr/share/keyrings/; che è la destinazione indicata dalla policy Debian (come feci notare anche a suo tempo). Invece da due mesi scriviamo nel wiki di salvarle in /etc/apt/keyrings.

Non so se hanno cambiato la wiki di debian nel frattempo, ma io leggo:

If future updates to the key will be managed by an apt/dpkg package as recommended below, then it SHOULD be downloaded into /usr/share/keyrings using the same filename that will be provided by the package. If it will be managed locally , it SHOULD be downloaded into /etc/apt/keyrings instead.

Quindi, se ho capito bene, se l'aggiunta viene fatta manualmente dall'utente (amministratore) del sistema, la relativa chiave andrebbe posta in /etc/apt/keyrings; mentre se la gestione della chiave è demandata ad un pacchetto con dpkg/apt (tipo il deb di chrome che aggiunge i repo automaticamente), questa andrebbe posta (dal pacchetto) sotto /usr/share/keyrings.

L'importante è non metterla in /etc/apt/trusted.gpg.d

The key MUST NOT be placed in /etc/apt/trusted.gpg.d or loaded by apt-key add.

https://wiki.debian.org/DebianRepositor ... stribution

[wilecoyote]

) Salve, la wiki di Debian l'avevo letta e pure postato il link, qualche post più sù, ed è in virtù di ciò che proposi l'uso di /etc/apt/keyrings, oltretutto col vantaggio non trascurabile di poter vedere al volo quali chiavi sono state aggiunte.

Mentre se getti un occhio in /usr/share/keyrings vedrai che è già affollata di suo di quelle del sistema, rischiando in caso di rimozione «brevi manu» di rimuovere quella sbagliata.

:: Ciao

[xavier77]

Non so se hanno cambiato la wiki di debian nel frattempo, ma io leggo:

If future updates to the key will be managed by an apt/dpkg package as recommended below, then it SHOULD be downloaded into /usr/share/keyrings using the same filename that will be provided by the package. If it will be managed locally , it SHOULD be downloaded into /etc/apt/keyrings instead.

Per la cronaca sì, avevano cambiato il wiki di Debian qualche ora prima che pubblicassimo la guida
Sono andato a vedermi la cronologia, visto che mi ricordavo che /etc/apt/keyrings non veniva nemmeno citato in quella pagina...

) Salve, la wiki di Debian l'avevo letta e pure postato il link, qualche post più sù, ed è in virtù di ciò che proposi l'uso di /etc/apt/keyrings, oltretutto col vantaggio non trascurabile di poter vedere al volo quali chiavi sono state aggiunte.
Mentre se getti un occhio in /usr/share/keyrings vedrai che è già affollata di suo di quelle del sistema, rischiando in caso di rimozione «brevi manu» di rimuovere quella sbagliata.

Quando tu ne parlavi (inizio maggio) nel wiki di Debian non c'era traccia di /etc/apt/keyring
Comunque non può essere la "comodità" che hai individuato l'unica motivazione.
E il motivo è evidente, mi sembra anche banale riportarlo: a questo punto se inizi ad «affollare»/etc/apt/keyrings di chiavi, il rischio che dici si ripropone; in più se si seguisse tale principio non si dovrebbero mettere più di un tot di file in qualsiasi cartella .

Ritornando a noi, sono andato a spulciarmi il changelog (versione di apt 2.4.0 [ Julian Andres Klode ]), appuntato sempre nella history della guida di Debian:
https://launchpad.net/ubuntu/+source/apt/+changelog
e leggo:

Codice: Seleziona tutto

  * Install an empty /etc/apt/keyrings directory.
    This directory is intended to provide an alternative to
    /usr/share/keyrings for placing keys used with signed-by.
  * Warn if the legacy trusted.gpg keyring is used for verification

Il primo punto mi sembra che parli da solo.
Inoltre vedo qui, su macchina virtuale 20.04:

Codice: Seleziona tutto

ls /usr/share/keyrings
brave-browser-archive-keyring.gpg  ubuntu-advantage-esm-infra-trusty.gpg  ubuntu-archive-keyring.gpg          ubuntu-master-keyring.gpg
ubuntu-advantage-cc-eal.gpg       [....] ubuntu-advantage-esm-apps.gpg      ubuntu-advantage-ros.gpg               ubuntu-cloudimage-removed-keys.gpg

Mi sembrano tutte chiavi aggiunte dal "sistema Ubuntu". Quindi, in altre parole, in /etc/apt/keyrings andrebbero quelle aggiunte "a mano" (signed-by).
Perciò l'intento sarebbe di tenere separate le chiavi aggiunte dall'utente e quelle aggiunte automaticamente da apt, dpkg o altri strumenti.
Se non ho capito male.
Certo che due righe in più di chiarimento potevano scriverle

NB:
Fa eccezione della chiave di Brave, installato con i comandi della relativa guida (che ho linkato ieri).

Quindi OK, per il momento deduco che stiamo andando nella direzione giusta.
Se qualcuno è in grado di fornire altre fonti o altre info in generale sarebbe molto apprezzato.

[wilecoyote]

) Salve, credevo che fosse nella wiki di Debian che indicai, la spiegazione di come usare la path /etc/apt/keyrings, di cui ancora ignoravo la provenienza, sarà stata in qualche altra documentazione trovata mentre scartabellavo in rete.

C'è una differenza tra rimuovere una chiave in /etc/apt/keyrings ed una in /usr/share/keyrings, nel 1° caso blocchi l'aggiornamento d'una applicazione aggiunta a posteriori, nel 2° rischi di bloccare l'aggiornamento del sistema.

:: Ciao

[frapox]

Non so se hanno cambiato la wiki di debian nel frattempo, ma io leggo:

If future updates to the key will be managed by an apt/dpkg package as recommended below, then it SHOULD be downloaded into /usr/share/keyrings using the same filename that will be provided by the package. If it will be managed locally , it SHOULD be downloaded into /etc/apt/keyrings instead.

Per la cronaca sì, avevano cambiato il wiki di Debian qualche ora prima che pubblicassimo la guida
Sono andato a vedermi la cronologia, visto che mi ricordavo che /etc/apt/keyrings non veniva nemmeno citato in quella pagina...

Sì, infatti la ricordavo diversa, non menzionava /etc/apt/keyrings. Beh direi che ora non ci sono più dubbi su dove vadano messe le chiavi.

Alla fine anche il FSH vuole così, /etc per i settaggi "system wide" fatti dagli amministratori, /usr invece viene gestito dal vendor (la distribuzione e il package management in generale).

C'è una differenza tra rimuovere una chiave in /etc/apt/keyrings ed una in /usr/share/keyrings, nel 1° caso blocchi l'aggiornamento d'una applicazione aggiunta a posteriori, nel 2° rischi di bloccare l'aggiornamento del sistema.

Fonte o prove di questa affermazione?

[wilecoyote]

) Salve, fai una prova, elimina le chiavi di Ubuntu e prova l'aggiornamento.

Posta i risultati, finora so solo cosa successe quando rimuovetti per errore la chiave di Anydesk, aggiornamento non possibile causa mancanza delle chiavi.

:: Ciao

[frapox]

) Salve, fai una prova, elimina le chiavi di Ubuntu e prova l'aggiornamento.

Posta i risultati, finora so solo cosa successe quando rimuovetti per errore la chiave di Anydesk, aggiornamento non possibile causa mancanza delle chiavi.

rimuovetti? Siamo in un film di Fantozzi per caso? Semmai "rimossi".
https://it.bab.la/coniugazione/italiano/rimuovere

È ovvio che se rimuovi una chiave dei repo principali di ubuntu poi ti si pianta qualsiasi operazione con apt. Ma questo avviene non a causa della directory in cui si trova la chiave (che era il discorso che si stava facendo, cioè capire cosa andasse messo dove), ma perché rimuovi una chiave che serve ad autenticare i pacchetti e i metadati dei dei repo ufficiali.

Che fatica!!!

[wilecoyote]

) Salve, aggiunte procedure per estrarre e spostare le chiavi da /etc/apt/trusted.gpg & /etc/apt/trusted.gpg .d a /etc/apt/keyrings, eseguita nella pagina di prova wilecoyote/GestioneRepositoryTerzeParti.

:: Ciao

[xavier77]

) Salve, aggiunte procedure per estrarre e spostare le chiavi da /etc/apt/trusted.gpg & /etc/apt/trusted.gpg .d a /etc/apt/keyrings, eseguita nella pagina di prova wilecoyote/GestioneRepositoryTerzeParti.
:: Ciao

Le info son molto valide e utili e mancava ancora nella guida la procedura di esportazione di chiavi in /etc/apt/trusted.gpg.
Le ho prese quindi dalla tua pagina di prova e importate nel paragrafo esistente.
Ho cercato di sintetizzare per non allungare la guida (ad esempio anche sforbiciando l'output di sudo apt-key list) e di mantenere standard e nomenclature finora utilizzati nella guida (vedi i nomi di esempio).
Grazie a wilecoyote e controllate tutti se mi son scappati refusi ecc.

[wilecoyote]

) Salve, m'è bastato chiedere al sistemista giusto qual'erano i comandi giusti, e poi paciugare allegramente il mio output di apt-key list in Kubuntu Bionic, per anonimizzarlo, per creare il paragrafo.

:: Ciao

[xavier77]

) Salve, m'è bastato chiedere al sistemista giusto qual'erano i comandi giusti

Bastava aver letto le discussioni su forum internazionali (pagina precedente) oppure certe guide, come quella fatta bene su itsfoss.com, che trovi scorrendo sopra.
Al momento della prima stesura si era fatto cenno alle chiavi in /etc/apt/trusted.gpg.d, ma mi ero completamente dimenticato di quelle nel file trusted.gpg.
Comunque aggiunta una nota (perché il messaggio Manage keyring files in trusted.gpg.d instead può essere fuorviante) e alcune piccole correzioni.

poi paciugare allegramente il mio output di apt-key list in Kubuntu Bionic, per anonimizzarlo, per creare il paragrafo.

Ma scusa, perché usi la 18.04 per lavorare su una guida verificata con 22.04 ??????????!!!!!!!!!!!!!!???????????
Ecco la possibile spiegazioni di alcune sensibili differenze del comando apt-key list che c'erano nella tua pagina di prova con quelle che mi ero ritrovato...

Ritornando a noi, alcune guide come questa fanno eseguire dopo l'esportazione:

Codice: Seleziona tutto

sudo apt-key del ID-key

per eliminare la chiave da trusted.gpg (dove ID-key sono sempre le ultime 8 cifre dell'ID della chiave)
Effettivamente la pagina man non dice che apt-key export sposti la chiave da trusted.gpg.
Adesso non ho la macchina virtuale 22.04 per controllare, ma dovrebbe essere molto semplice; infatti basterebbe ridare

Codice: Seleziona tutto

sudo apt-key list

e vedere se la chiave è ancora lì.

[wilecoyote]

) Salve, le prove l'ho fatte coi miei personali sistemi D/P/Tubuntu, dopo avanzamento da Focal a Jammy.

Ho usato l'output del Bionic per lo stesso motivo per cui ho paciugato il listato, renderlo anonimo.

Sulla persistenza della chiave hai ragione, pur estratte in /etc/apt/keyrings sono ancora presenti in /etc/apt/trusted.gpg.

2 osservazioni, il comando post estrazione che proponi le elimina e quindi possiamo senz'altro aggiungerlo, male non fa ed hai visto mai che il fortunello di turno…

Dopo consulto telefonico ho avuto conferma che comunque il sistema le ignora in virtù dell'opzione [signed-by=...], cosa ovvia dato che non ho segnalazioni di doppie chiavi durante gli aggiornamenti.

:: Ciao

[xavier77]

Ho usato l'output del Bionic per lo stesso motivo per cui ho paciugato il listato, renderlo anonimo.

OK ma ripeto: quando lavori su una guida per Ubuntu versione X non devi farlo con una Ubuntu versione Y.
Questa volta di diverso c'era solo una bazzecola (diverso formato dell'output di apt-key list: «non nota» al posto di «sconosciuto»). Un'altra volta potrebbero esserci delle differenze tali da compromettere un'intera procedura.

2 osservazioni, il comando post estrazione che proponi le elimina e quindi possiamo senz'altro aggiungerlo, male non fa ed hai visto mai che il fortunello di turno…
Dopo consulto telefonico ho avuto conferma che comunque il sistema le ignora in virtù dell'opzione [signed-by=...], cosa ovvia dato che non ho segnalazioni di doppie chiavi durante gli aggiornamenti.

Non sto proponendo nulla, mi limito a segnalare quello che trovo su documentazioni, changelog, guide di terze parti ecc.
Comunque sì, eliminare la chiave in /etc/apt/trusted.gpg in teoria dovrebbe essere ininfluente, poiché il parametro [signed-by=...] richiamerà la chiave giusta.
Va be', appena posso controllo sulla VM 22.04.


EDIT: ho provato adesso e confermato quanto detto prima. Aggiunto alla guida il passaggio, come facoltativo.

[wilecoyote]

) Salve,

2 osservazioni, il comando post estrazione che proponi le elimina e quindi possiamo senz'altro aggiungerlo, male non fa ed hai visto mai che il fortunello di turno…
Dopo consulto telefonico ho avuto conferma che comunque il sistema le ignora in virtù dell'opzione [signed-by=...], cosa ovvia dato che non ho segnalazioni di doppie chiavi durante gli aggiornamenti.

Non sto proponendo nulla, mi limito a segnalare quello che trovo su documentazioni, changelog, guide di terze parti ecc.
Comunque sì, eliminare la chiave in /etc/apt/trusted.gpg in teoria dovrebbe essere ininfluente, poiché il parametro [signed-by=...] richiamerà la chiave giusta.
Va be', appena posso controllo sulla VM 22.04.


EDIT: ho provato adesso e confermato quanto detto prima. Aggiunto alla guida il passaggio, come facoltativo.

Ottimo, tramite ripetizione dell'empirismo a cui già provvidi nelle 3 LTS al momento supportate, sei passato dalla teoria alla conferma, anche questa è scienza del ramo informatico.

:: Ciao

[wilecoyote]

) Salve, c'è la rivolta dei repository terzi contro il deprecamento dell'apt-key.

Dopo Skype segnalato qui Pagine Skype e Skype/Amd64, e Opera segnalato qui Guida browser Opera, adesso anche Microsoft Edge e Vivaldi sovrascrivono il loro file repository in /etc/apt/sources.list.d/.

A questo punto propongo d'aggiungere questo comando a tutti gli imbelli:

Codice: Seleziona tutto

sudo chattr +i /etc/apt/sources.list.d/<nome repository>.list

Usando come <nome repository> quello creato in automatico all'aggiornamento, ovvero vivaldi, opera-stable, skype-stable e microsoft-edge.

Firefox, Pale Moon, Waterfox e Brave Browser al momento non palesano intenzioni rivoltose.

:: Ciao

[xavier77]

Poiché mi pare non sia una soluzione "ufficiale" (benché funzioni), per fare prima, per mantenere un pochino d'ordine, ma anche per fornire ai lettori un minimo di spiegazioni, aggiungerei un paragrafo Soluzione dei problemi, scritto più o meno così:

Alcuni programmi di terze parti dopo l'aggiornamento riscrivono potrebbero riscrivere il file dei rispettivi repository, all'interno della directory /etc/apt/sources.list.d.
Questo potrebbe portare a dei messaggi di errore durante i successivi aggiornamenti.
In tal caso è possibile

• Riscrivere il file .list dell'applicazione. [Tip: il vecchio contenuto dovrebbe essere consultabile del file /etc/apt/sources.list.d/applicazione.list.save]
• Adottare il seguente wordaround, rendendo immutabile il file con il comando:

  Codice: Seleziona tutto

  sudo chattr +i /etc/apt/sources.list.d/<nome repository>.list

Il link alla procedura andrebbe poi messo nelle guide dove serve (Skype,Edge, Opera ecc.).

[wilecoyote]

) Salve, non potrebbero riscrivere il file dei rispettivi repository, ma riscrivono il file dei rispettivi repository…

È una problematica afferente i derivati di Chromium, tranne Brave Browser a giudicare da gli ultimi aggiornamenti.

Aggiungo alla lista il VisualStudioCode, e per verificare ieri sera ho adeguato le wiki alla nuova problematica per farle provare «brevi manu».

Che m'ha procurato contumelie sul termine mutarlo, ed indicandomi di correggerlo in mutabile.

Le pagine di prova delle applicazioni coinvolte sono wilecoyote/Browser/Opera, wilecoyote/Browser/Vivaldi, wilecoyote/Browser/MicrosoftEdge, wilecoyote/Skype e wilecoyote/Ufficio/VisualStudioCode.

Continuo le verifiche e prove della pagine di prova.

:: Ciao