• [^] # Re: E-mail sans support du client

    Posté par . En réponse au journal Bien démarrer avec GnuPG. Évalué à 4.

    pourquoi, si c'est pas indiscret ?

    En gros, parce que les listes de discussion ont des traditions douteuses qui persistent aujourd’hui et que Git a un support seulement minimaliste du format MIME.

    ...

    D’accord, j’explique.

    J’envoie des patchs sur une liste de discussion qui, comme (malheureusement) beaucoup de listes, juge utile de modifier les messages pour ajouter un footer contenant des informations sur la liste elle-même (typiquement un lien vers les archives de la liste sur le web, et un lien vers un formulaire de désinscription).

    C’est-à-dire que j’envoie un message constitué d’une seule part MIME (contenant le patch précédé du message de commit), et il est transformé par le logiciel de la liste de discussion en un message avec la structure suivante :

    • multipart/mixed (conteneur MIME)
      • text/plain (corps du message original, contenant le patch)
      • text/plain (« pied de page » de la liste de discussion)

    Pour l’instant, pas de problème : git am est capable de comprendre cette structure et d’extraire le patch de la part MIME qui le contient.

    Quand on signe un e-mail au format PGP/MIME, le mail résultant a la structure suivante :

    • multipart/signed (conteneur MIME)
      • text/plain (corps du message original)
      • application/pgp-signature (signature)

    Là encore, pas de problème pour l’instant, git am peut gérer ça.

    Le problème survient quand on envoie un tel message sur une liste de discussion qui rajoute un pied de page. Parce que là, le message final ressemble alors à ça :

    • multipart/mixed (conteneur MIME)
      • multipart/signed (conteneur MIME)
      • – text/plain (corps du message original, contenant le patch)
      • – application/pgp-signature (signature)
      • text/plain (pied de page de la liste de discussion)

    Et ça, c’est une structure que git am ne comprend pas et dont il est incapable d’extraire le patch. Du coup, ça casse le workflow du développeur upstream et augmente considérablement le risque que le patch ne soit purement et simplement ignoré.

    Le problème ne vient pas du message lui-même. Cette structure à plusieurs niveaux est une structure MIME parfaitement valide. C’est Git qui ne gère pas les conteneurs MIME imbriqués. Globalement, Git a un support très réduit de MIME, comme ses développeurs le reconnaissent ouvertement dans ce commentaire (mailinfo.c, lignes 213–216) :

    /* NOTE NOTE NOTE. We do not claim we do full MIME. We just attempt
 * to have enough heuristics to grok MIME encoded patches often found
 * on our mailing lists. For example, we do not even treat header lines
 * case insensitively.
 */