Le mécanisme
Ce qui se dresse entre un plugin et vos fichiers.
Quatre étapes distinctes, dont chacune peut refuser : la relecture, l’entrée de catalogue, le téléchargement, et les permissions que vous accordez ensuite.
01Une version est immuable une fois publiée
L’archive est construite de façon déterministe et son SHA-256 consigné. Une nouvelle soumission dont les octets diffèrent est refusée plutôt que fusionnée : toute modification — même une seule ligne reformulée — doit devenir une nouvelle version avec sa propre relecture.
02L’empreinte est revérifiée sur votre machine
Après le téléchargement, l’app recalcule le SHA-256 et le compare à la valeur relue, et vérifie que la taille correspond à celle enregistrée. Une différence refuse l’installation purement et simplement plutôt que d’avertir.
03L’URL de téléchargement ne peut pas pointer ailleurs
Une entrée de catalogue n’est acceptée que si son URL de téléchargement est en https, sur linelark.com, au chemin exact de ce plugin et de cette version, sans chaîne de requête ni fragment. Un catalogue altéré ne peut pas rediriger une installation vers un autre hôte.
04L’archive elle-même est contrainte
Aucun lien symbolique, aucun chemin sortant du bundle, 1 000 entrées au maximum, 20 Mo décompressés et 50 Mo compressés au maximum. Un zip qui tente l’un de ces écarts est rejeté avant que rien ne soit écrit.
05Les capacités sont déclarées, puis accordées séparément
Le manifeste demande l’accès en écriture à git, des hôtes nommés, et des identifiants nommés. Installer n’accorde rien — vous activez chaque élément dans Gérer les plugins, et le panneau montre exactement ce qui a été demandé.
06Changer ce qu’un plugin demande révoque votre accord
Les permissions sont liées à une empreinte des capacités du manifeste. Une mise à jour qui ajoute un hôte, ou qui déplace un identifiant vers un autre en-tête, doit redemander depuis zéro plutôt que d’hériter du oui donné à la version précédente.