Pb de clé GPG expirée sur un dépôt tiers

Support Debian
#1

Bonjour,
C’est mon tout premier post sur ce forum. En général j’arrive à me débrouiller en trouvant deci delà la solution. Mais là je cale et ça commence à me titiller ! Je ne me suis guère penché sur la problématique des dépôts et de leur signature car Jusqu’à présent ça roulait presque tout seul.

Je souhaite mettre à jour MongoDB 3.6 sur une Debian 11.7. Pour ce faire, il n’est pas possible de passer directement à la dernière version, il faut procéder itérativement, en commençant par la 4.0. Et là c’est le drame. La signature du dépôt MongoDB de cette version 4.0 a expiré depuis le mois d’avril et cela ne passe bien évidemment pas avec apt :

W: GPG error: http//repo.mongodb.org/apt/debian stretch/mongodb-org/4.0 Release: The following signatures were invalid: EXPKEYSIG 68818C72E52529D4 MongoDB 4.0 Release Signing Key <\packaging@mongodb.com>

Quand on regarde la clé avec apt-key list :

    pub   rsa4096 2018-04-18 [SC] [expired: *2023-04-17*]
          9DA3 1620 334B D75D 9DCB  49F3 6881 8C72 E525 29D4
    uid           [ expired] MongoDB 4.0 Release Signing Key \<\packaging@mongodb.com>

Le truc amusant, c’est que la v3.6 a une clé qui expire fin 2023 …
Visiblement je ne suis pas le seul à avoir le souci :

Voici le fichier des sources utilisé :

deb http//repo.mongodb.org/apt/debian stretch/mongodb-org/4.0 main

D’abord j’ai essayé de faire le maj de la clé, sans succès

apt-key adv --keyserver hkp://keyring.debian.org:80 --recv-keys 68818C72E52529D4

→ gpg: no valid OpenPGP data found.

donc a priori Debian n’a pas.

Avec Ubuntu

apt-key adv --keyserver keyring.debian.org --recv-keys 68818C72E52529D4

→ gpg: unchanged: 1
Donc ça change pas grand chose. J’en déduis que je vais pas changer une clé périmée. Il faut procéder différemment.

Donc j’essaye de ne pas tenir compte des signatures au niveau du fichier des sources :

deb [trusted=yes] http//repo.mongodb.org/apt/debian stretch/mongodb-org/4.0 main

Mais cela n’a eu aucune incidence.

Ensuite j’essaye au niveau d’apt :

apt-get -o Acquire::Check-Valid-Until=false update

et

apt-get --allow-unauthenticated --allow-insecure-repositories update

→ pas mieux, toujours l’erreur de clé gpg !

Avant de passer à une install manuelle du deb, j’aurais souhaité savoir si j’ai loupé quelque chose, ou bien s’il n’y a rien à faire côté apt quand un package a une signature périmée ??? Merci

#2

clef expiré c’est normal. N’y a-t-il pas une version plus récente? ta debian est-elle sous stretch? auquel cas tu as versions majeure de retard.

#3

Comme indiqué, je suis en Debian 11.7. Mais pour avoir une version MongoDB 4.0, il faut passer par un dépôt Stretch…

#4

Pourquoi 3.6 alors que celles disponibles pour Bullseye sont:

https://repo.mongodb.org/apt/debian/dists/bullseye/mongodb-org/
4.2 - 4.4 - 5.0 - 6.0 - 7.0
1 J'aime
#5

Actuellement j’ai une 3.6 installée Et avec Mongold, pour upgrader à la 6.0 par exemple, il faut passer par les 4.0, 4.2, 4.4, 5.0 et enfin 6.0.

#6

Ça me parait très très étrange. Où as-tu vu ça ?
Ou alors, pourquoi ne pas repartir sur une 6 propre et réimporter ce que tu dois réutiliser ?

Install MongoDB Community Edition on Debian — MongoDB Manual

curl -fsSL https://pgp.mongodb.com/server-6.0.asc | \
   sudo gpg -o /usr/share/keyrings/mongodb-server-6.0.gpg \
   --dearmor

echo "deb [ signed-by=/usr/share/keyrings/mongodb-server-6.0.gpg] http://repo.mongodb.org/apt/debian bullseye/mongodb-org/6.0 main" | sudo tee /etc/apt/sources.list.d/mongodb-org-6.0.list

apt update
apt install mongodb-org
#7

C’est la procédure de maj MongoDB. Je n’y peux rien. Exemple :

Et si tu respectes pas, tu cours un risque de corruption de données :
https://jira.mongodb.org/browse/WT-6623
Quand à repartir « from scratch » depuis une v6.0 : c’est une appli tierce qui utilise MongoDB , donc ce n’est pas moi le dba de cette base (surtout que ma spécialité c’est SQL Server : j’y connais rien en nosql !).

#8

Au cas où, as tu essayé de supprimer la clé invalide de ton trousseau apt-key avant de relancer avec ta source en

deb [trusted=yes]

Si ça se trouve, il vérifie la validité de la clé dans ton trousseau, voit que la clé est expirée, et ne se préoccupe même pas du trusted=yes, donc si tu ne le laisse pas voir l’invalidité de la clé, peut être qu’il va prendre en compte le [trusted=yes] ?
Enfin je ne sais pas si je me suis bien exprimé, mais c’est une idée à tester.

#9

Notez que j’ai mis 30s à installer manuellement de deb là où j’ai mis au moins 2 bonnes heures à essayer de résoudre ce pb de clé périmée !!!

Mais tout de même, pourquoi les 2 mesures indiquées dans mon 1er post pour outrepasser la vérification des signatures par apt ne fonctionnent-elles pas ???

Il y a aussi un dernier point : apt-jky est une commande obsolète, il faut dormais utiliser gpg. Mais là aussi rien n’est simple : je n’ai pas réussi faire fonctionner correctement apt quand j’importe les clés avec gpg. Probablement une question de paramétrage d’apt ?

#10

Si ma suggestion de suppression fonctionne, c’est qu’il y a un bug à signaler.

Alors non, apt-key est deprecated pour buster (11), mais pas encore supprimée, elle n’est sensée disparaitre que dans bookworm (12).
L’ancien système fonctionne encore avec des warnings, il me semble, d’ou ta réussite en l’utilisant, sans doute.
Aprés, je ne sais pas trop pourquoi ce que tu as fait avec gpg n’a pas marché, peut être que c’est lié au fait que tu tapes dans des dépots stretch ?

#11

Ta conclusion n’est qu’une interprétation d’échanges sur un forum.
Ce n’est pas parce-que lorsque la version 4.57 est sortie qu’on expliquait comment passer de 3.6 à 4.57 que tu peux extrapoler que tu dois faire des itérations d’installation de 4.0, 4.2, 4.4, 5.0 et enfin 6.0.
Et la référence n’est pas des échanges relatifs à ubuntu, mais le manuel MongoDB qui explique clairement comment installer MongoDB dans bullseye.

Oui l’importation de clefs gpg a évolué depuis buster.
J’ai testé l’importation de clef de la V6 comme indiqué: aucun problème.

#12

MongoDB est déjà une appli tierce.
Donc une appli tierce qui utilise une appli tierce, ça devient compliqué sur un forum Debian, surtout si tu n’y connais rien en MongoDB et en nosql.
Finalement, fais comme tu sens…

#13

Pas tout à fait :
To upgrade an existing MongoDB deployment to 4.4, you must be running a 4.2-series release.
https://www.mongodb.com/docs/manual/release-notes/4.4-upgrade-standalone/
To upgrade an existing MongoDB deployment to 5.0, you must be running a 4.4-series release.
https://www.mongodb.com/docs/manual/release-notes/5.0-upgrade-standalone/
To upgrade an existing MongoDB deployment to 6.0, you must be running a 5.0-series release.
https://www.mongodb.com/docs/manual/release-notes/6.0-upgrade-standalone/
C’est pareil avec SQL Server.

Ma question portait sur l’installation d’un package et sur la gestion des clés de dépôts avec un distro Debian, pas sur MongoDB ou nosql ! C’est un problème générique.

#14

Oui j’ai testé. Cela ne règle pas le souci, cela change juste le message d’erreur :
W: GPG error: http://repo.mongodb.org/apt/debian stretch/mongodb-org/4.0 Release: The following signatures couldn’t be verified because the public key is not available: NO_PUBKEY 68818C72E52529D4
Cela me semble bizarre, je vais tâcher d’investiguer un peu plus là-dessus !

#15

Je laisse libre cours à tes interprétations relativement à la V6.

->> comme déjà dit, oublie des dépôts stretch pour bullseye.

Tu es en 3.6.
Tu as de dispo 4.2 - 4.4 - 5.0 - 6.0 - 7.0 pour bullseye.
Tu veux laquelle ?

#16

Alors j’ai une autre suggestion « sale »: installer le paquet concerné avec dpkg -i (ou plutôt debi, qui fait quelques vérifications de dépendances supplémentaires il me semble).
Tu vas chercher sur MongoDB Repositories l’url de la version du paquet .deb mongodb que tu veux, tu l’importes sur ta machine avec wget, puis tu l’installes avec debi:
debi <tonpaquet>.deb
(avec dpkg, c’est:
dpkg -i <tonpaquet>.deb
mais je crois que c’est moins « sûr » que debi qui - il me semble - car sans vérif de dépendance)
Encore une fois, on rentre dans le « sale », donc faut prévoir une sauvegarde.

Juste pour info, quand un individu ne fait que mépriser, faire son prétentieux, et intervenir à tort et à travers sans jamais aucune proposition utile, tu peux le muter en passant sur son profil, et tu n’as plus à subir ses interventions pénibles, c’est une fonctionnalité cool que j’ai découverte sur ce forum.

#17

APT le fais dorénavant, mais il va sans doute après coup cherché des dépendances (si il en a besoin sur les dépôts qui seront bloqué à cause des clés GPG).

Après je plussoie la méthodologie, oublie les dépôts le temps d’être à jour.

Télécharge les binaire (c’est que préconise Mongo eux même) et installe en respectant leur procédures :

Il te faudra monter de version en passant par les intermédiaires et en ajustant les compatibilités, si tu as un DBA c’est le bon moment pour qu’il mérite son salaire :innocent:
Franchement je fuis Mongo, node et consorts sur mes projets à cause de ça.

#18

Salut @Clochette

#19

Je plussoie, ce sont des DB qui finissent souvent sale au bout d’un certain temps.

#20

:wink: salut