Winget: le gestionnaire de packages remplie d’applications dupliquées ou mal formées

0

La semaine dernière, Microsoft a publié la première version stable de son gestionnaire de packages sur Windows 10 nommé Winget qui permet aux utilisateurs de gérer des applications via la ligne de commande.

Tout comme les gestionnaires de paqckages disponibles sur d’autres plates-formes, Winget permet aux utilisateurs de Windows d’automatiser la gestion des applications lorsqu’il s’agit d’installer, de configurer, de mettre à niveau et de désinstaller des applications.

Mais plusieurs utilisateurs ont inondé le registre des logiciels de Winget avec des demandes d’extraction d’applications dupliquées ou mal formées, soulevant ainsi des inquiétudes quant à l’intégrité de l’écosystème de Winget.

Le référentiel de Winget inondé d’applications dupliquées, de manifestes malformés

Microsoft avait présenté pour la première fois la version préliminaire de son gestionnaire de packages de Windows 10 lors de Microsoft Build 2020. Depuis lors, Microsoft a développé Winget en tant que projet open source sur GitHub.

La dernière semaine de Mai a marqué une étape importante avec la sortie de la première version stable de Winget.

Les directives de Microsoft indiquent que les éditeurs de logiciels indépendants (ISV) cherchant à télécharger leur application dans le registre de Winget peuvent le faire en soumettant le manifeste de l’application sur leur GitHub.

De plus, lorsque les contributeurs soumettent un manifeste sur le GitHub de Winget, à quelques exceptions près, les manifestes sont automatiquement validés par le bot de Winget en fonction de critères définis.

Cependant, plusieurs demandes d’extraction ont émergé sur le GitHub de Winget contenant des noms d’applications qui existaient déjà dans le registre du gestionnaire de paquets.

De plus, certaines demandes d’extraction contenaient des noms d’application incorrects dans les manifestes ou des liens « mauvais » à partir desquels l’application devait être récupérée.

Et, dans quelques autres cas, les nouvelles demandes d’extraction écraseraient les manifestes des applications existantes, avec des informations incomplètes.

L’utilisateur KaranKad a initialement discuté de ce problème, après avoir rassemblé plus de cinq douzaines d’exemples de demandes d’extraction non valides adressées au référentiel de Winget.

« Les gens soumettent des manifestes incorrects ou en double sans vérifier si l’application existe déjà ou non dans ce référentiel. »

« Créez un groupe de contributeurs actifs qui savent ce qu’ils font, avec [la] possibilité de fermer un PR afin qu’ils puissent empêcher l’entrée de PR mauvais ou en double », a suggéré l’utilisateur.

Parmi les nombreux exemples publiés, nous avons remarqué à quel point cela était particulièrement vrai pour une application nommée « PrimoPDF »:

Les fichiers manifestes de l’application PrimoPDF de NitroPDF contiendraient un PackageIdentifier (« NitroPDFIncNitroPDFPtyLtd.PrimoPDF ») mal formé et une URL de téléchargement.

Dans d’autres cas, les manifestes d’applications légitimes comme le lecteur VLC de VideoLAN et l’application Steam de Valve avaient été écrasés par les contributeurs, mais avec des informations incomplètes :

Il a été signalé que des écosystèmes open source tels que PyPI étaient inondés de composants de courrier indésirable.

Dans des cas plus graves, des composants contrefaits ont été détectés en train d’être téléchargés dans les référentiels npm et RubyGems.

Sans contrôle, ces paquets malformés, incomplets ou carrément malveillants peuvent ouvrir la voie à tout, des simples erreurs d’application à une attaque réussie de la chaîne d’approvisionnement.

Bien que ces demandes d’extraction de Winget, qui introduisaient des informations incomplètes dans les manifestes des applications aient été rapidement annulées [1, 2], que fait-on pour empêcher de tels cas à l’avenir ?

Les développeurs proposent plusieurs solutions

À la suite de cet incident, plusieurs développeurs ont suggéré des solutions de contournement ou des pratiques que Winget peut adopter pour garantir l’intégrité de ses packages.

« Je pense vraiment que tout nouveau PackageIdentifer devrait être vérifié par quelqu’un de l’équipe de Winget (ou s’ils veulent démarrer un système de contributeur reconnu, je jetterais mon chapeau dans le ring) », a suggéré Easton Pillay, un développeur et contributeur de Winget.

Pillay pense également que l’automatisation complète de l’ajout de nouveaux packages Winget introduira des tonnes de doublons.

Dans le même fil, le développeur a également proposé que les manifestes de Winget nouvellement créés nécessitent un examen manuel :

« Je sais que nous essayons de ne pas faire perdre du temps au modérateur, mais comme [les contributeurs] commettent par défaut de mauvaises métadonnées connues…, le bot ne s’en rend pas compte et quelqu’un qui sait que le bogue existe doit revenir en arrière et corrigez toutes les erreurs (ou vivre avec des métadonnées erronées, ce qui est une tragédie ;D) », a déclaré Pillay.

Demitrius Nelon de Microsoft, une personne clé derrière le développement de Winget, a reconnu le problème et ils envisagent de l’adresser avec l’équipe.

Nelon a également proposé une solution potentielle :

« L’une des options pourrait être d’exiger un ‘second’ approbateur sur un ‘nouveau’ manifeste dans un ‘nouveau’ répertoire. »

« Le bot a un concept qui pourrait fonctionner pour ce scénario. Je ne veux simplement pas mettre trop de friction et de retard pour les personnes soumettant des manifestes, ni trop de pression sur les ‘modérateurs’. »

« Nous avons une fonctionnalité sur le backlog pour détecter les doublons. C’est plus un avertissement qu’une action de blocage. Nous avons des scénarios de renommage ‘valides’ attendus », a expliqué Nelon.

Laisser un commentaire