Résumé

  • La version 03 du projet PDPArchive retient le conteneur POSIX pax, autorise gzip ou Zstandard et décrit un export découpé en plusieurs fichiers.
  • L’importateur doit refuser les chemins absolus, les remontées .. et les types d’entrée interdits avant toute écriture. Il doit créer les fichiers avec ses propres réglages, sans appliquer propriétaire, permissions, attributs étendus ou ACL venus du paquet.

Le carton contient une vie, pas un compte administrateur

Le groupe de travail Mail Maintenance veut rendre transportables courriels, contacts, calendriers et autres données personnelles. La révision précédente travaillait surtout sur les éléments internes. La nouvelle précise le contenant : pax, membre de la famille tar, avec des en-têtes étendus pour les noms et tailles. Les exportateurs devront produire ce format et n’y mettre que fichiers ordinaires ou répertoires. Le registre IETF montre toujours un Internet-Draft de groupe de travail, sans RFC adopté ni preuve d’un transfert réel.

Le nom d’une entrée d’archive décide de son futur emplacement. Le projet exige l’UTF-8, des chemins relatifs, aucun segment . ou .., et des noms uniques dans un fichier d’archive. À la réception, la validation doit précéder l’écriture : chemin absolu, sortie du répertoire parent ou entrée spéciale sont refusés. La règle la plus politique se cache dans les attributs techniques. L’importateur ne doit reprendre ni bits de mode, ni propriétaire, ni attributs étendus, ni listes de contrôle d’accès. C’est son environnement qui décide comment les nouveaux fichiers naissent. Le fournisseur quitté peut transmettre les données, pas distribuer les pouvoirs du fournisseur d’arrivée.

Deux noms distincts sur le papier peuvent aboutir au même fichier. Un système de fichiers ignorant la casse confondra Inbox et INBOX; une normalisation Unicode peut rapprocher d’autres noms. Le texte demande à l’exportateur d’essayer de préserver leur distinction au-delà de ces transformations et conseille à l’importateur de refuser les doublons au lieu d’en écraser un sans bruit. L’erreur serait invisible pour l’utilisateur qui croit avoir tout emporté.

L’archive peut aussi arriver en pièces détachées. Chaque partie doit être lisible seule et porter son archive.json; seuls part et final varient entre ces métadonnées générales. Si un gros dossier est réparti sur plusieurs parties, son UID et ses autres champs restent cohérents, et la liste removed est répétée. L’importateur doit réunir ces morceaux en un dossier, pas fabriquer des jumeaux. L’identité du dossier tient dans son UID, pas dans l’étiquette plus ou moins ressemblante de deux cartons.

Le projet accepte une archive nue, gzip ou Zstandard. Les importateurs devront prendre en charge les deux premiers cas et devraient prendre en charge le troisième. Le texte demande d’envisager taille décompressée, nombre d’entrées et taille de chacune pour résister à l’épuisement des ressources, sans imposer de plafond universel. Il avertit aussi que des rôles ou droits contenus dans un fichier téléversé peuvent avoir été modifiés. Ouvrir le conteneur ne revient pas à croire ses affirmations d’autorité.

La suite se jouera dans la décision du groupe de travail et dans des essais entre exportateurs et importateurs. Ces essais montreront si la sortie promise à l’utilisateur fonctionne sans emporter les privilèges de l’ancien serveur.

Sources : projet -03 ; projet -02 ; état IETF ; RFC 1952 ; RFC 8878.