[Plume] Whitelist new CVE

doc/guide_utilisateur_ci.md

@@ -37,6 +37,7 @@ Notez que le **nom final** de l'image construite est celui que vous indiquez dan
 Vous pouvez suivre les différentes étapes de la CI sur la page [Pipelines](https://gitlab.utc.fr/picasoft/projets/dockerfiles/pipelines), et il est **recommandé** de lire les logs des différentes étapes en cliquant sur chacune d'entre elles. Si la construction et les analyses de sécurité se passent bien, tous les voyants sont au vert (sauf la dernière étape, qui doit être déclenchée manuellement). Sinon, référez-vous à la section [Troubleshooting](#troubleshooting). Si l'analyse de sécurité n'est pas déclenchée, c'est qu'elle n'a pas besoin de l'être.
 
 Enfin, il est de bon ton de vérifier que les CVE whitelistées dans le fichier `clair-whitelist.yml` sont toujours détectées dans le scan de Clair (étape `clair`). Si non, on pourra les enlever de la liste.
+Notez aussi que souvent, les nouvelles CVE sont classées `High`, puis rétrogradée en `Medium`, voire `Negligeable`, parce qu'on s'est rendu compte que l'impact est moins grand qu'on le croyait. Dans ce cas, il convient d'enlever les CVE retrogradées de la liste blanche.
 
 On peut ensuite [déployer le service](guide_deploiement.md).
 

doc/mini_guide_cve.md

@@ -9,6 +9,10 @@ Une mise en liste blanche est **acceptable** si :
 * Il n'existe pas de contre-mesure à la vulnérabilité,
 * La vulnérabilité, même si elle est classée en criticité `High`, a peu de conséquences pour Picasoft. Cela peut être le cas pour une attaque par déni de service causant un usage de 100% du processeur, qui n'aura d'impact que sur Etherpad en raison des limitations de ressources.
 
+Si jamais il reste un paquet contenant une vulnérabilité `High`, et que les conditions ci-dessus ne sont pas remplies, voici deux choses à tenter avant de le whitelister ou de décider de ne pas déployer la mise à jour.
+
+## Suppression d'un paquet inutile
+
 On prend l'exemple de la `CVE-2020-8492 (High)` détectée par Clair lors d'un build de `pica-db-backup-rotation` ([commit](https://gitlab.utc.fr/picasoft/projets/dockerfiles/-/commit/078d448a53da4be9330fd0ac9304a7eb3a26e969), [log de Clair](https://gitlab.utc.fr/picasoft/projets/dockerfiles/-/jobs/883005))
 
 ![](./images/clair_log_1.png)

pica-plume/Dockerfile

-# Change as soon as the tag is published on Docker Hub :
-# https://hub.docker.com/r/plumeorg/plume/tags
-# For now 0.5.0 is not available
-ARG VERSION=latest
+ARG VERSION=v0.5.0
 FROM plumeorg/plume:${VERSION}
 
 ENV PLUME_VERSION=v0.5.0

pica-plume/README.md

@@ -18,6 +18,8 @@ Mettre à jour `VERSION` **et** `PLUME_VERSION` dans le [Dockerfile](./Dockerfil
 
 Vérifier que les vulnérabilités de [clair-whitelist.yml](./clair-whitelist.yml) n'ont toujours pas de contre-mesures, sinon appliquez les contre mesures (une mise à jour peut tout à faire résoudre le problème, dans ce cas pensez à enlever les vulnérabilités).
 
+**Attention : vérifier le passage de [l'image de base](https://github.com/Plume-org/Plume/blob/master/Dockerfile) à Debian Buster** : quand ce sera fait, le nombre de CVE diminuera très fortement.
+
 ### Configuration et lancement
 
 Copier le fichier `plume.secrets.example` dans `plume.secrets` et `plume_db.secrets.example` dans `plume_db.secrets` et remplacez les valeurs par des mots de passe de production.

pica-plume/clair-whitelist.yml

@@ -11,3 +11,4 @@ generalwhitelist:
   CVE-2020-13630: sqlite3 -> dépendance du client PG utilisé uniquement dans l'entrypoint
   CVE-2020-10543: perl -> trop de paquets en dépendent, pas de contre mesures
   CVE-2020-10878: perl -> trop de paquets en dépendent, pas de contre mesures
+  CVE-2020-14155: pcre3 -> pas de contre-mesure