3 pièce(s) jointe(s)
Google prévoit d'apporter un support plus affiné aux modules dans Go 1.12
Google prévoit d'apporter un support plus affiné aux modules dans Go 1.12,
l'entreprise donne des détails aux développeurs
Go 1.11, publié en août 2018, introduit un support préliminaire pour les modules. Pour l'instant, la prise en charge des modules est maintenue parallèlement aux mécanismes traditionnels basés sur GOPATH. La commande go utilise par défaut le mode module lorsqu'elle est exécutée dans des arborescences de répertoires situées en dehors de GOPATH / src et marquées par des fichiers go.mod dans leurs racines. Ce paramètre peut être remplacé en définissant la variable d'environnement de transition $ GO111MODULE sur on ou off; le comportement par défaut est le mode automatique. L’équipe responsable de Go indique qu’elle a déjà constaté une adoption importante des modules dans la communauté Go, ainsi que de nombreuses suggestions utiles et des rapports de bogues ayant pour optique de l’aider à améliorer les modules.
Go 1.12, prévu pour février 2019, affinera le support du module mais le laissera toujours en mode automatique par défaut. Outre de nombreuses corrections de bogues et autres améliorations mineures, le changement le plus important dans Go 1.12 est que des commandes telles que go run x.go ou go get rsc.io/2fa@v1.1.0 peuvent désormais fonctionner en mode GO111MODULE = on sans fichier go.mod explicite.
Citation:
Envoyé par Equipe Go
Notre objectif est que Go 1.13, prévu pour août 2019, active le mode module par défaut (c'est-à-dire, modifie le mode par défaut d'auto à activé) et déconseille le mode GOPATH. Pour ce faire, nous avons travaillé sur une meilleure prise en charge de l'outillage avec un meilleur support de l'écosystème de modules open source.
Intégration IDE et outillage
L’équipe rappelle que depuis huit ans qu’elle a lancé GOPATH, un nombre incroyable d’outils a été créé, qui suppose que le code source de Go est stocké dans GOPATH. Le passage aux modules nécessite donc la mise à jour de tout le code qui en découle. C’est pour cela qu’elle a conçu un nouveau paquetage, golang.org/x/tools/go/packages, qui résume l’opération de recherche et de chargement d’informations sur le code source Go d’une cible donnée. Ce nouveau paquet s'adapte automatiquement au mode modules et à GOPATH et est également extensible aux dispositions de code spécifiques aux outils, telles que celle utilisée par Bazel. L’équipe a travaillé de concert avec des auteurs d’outils de toute la communauté Go pour les aider à adopter golang.org/x/tools/go/packages dans leurs outils.
Citation:
Envoyé par Equipe Go
Dans le cadre de cet effort, nous travaillons également à unifier les divers outils d’interrogation de code source tels que gocode, godef et go-outline en un seul outil pouvant être utilisé à partir de la ligne de commande et prenant également en charge le protocole de serveur de langage utilisé par les EDI modernes.
La transition vers les modules et les modifications du chargement des packages ont également entraîné une modification importante de l'analyse du programme Go. Dans le cadre de la refonte de go vet pour prendre en charge les modules, l’équipe a introduit un framework généralisé pour l’analyse incrémentielle des programmes Go, dans lequel un analyseur est appelé pour un package à la fois.
Index du module
Une des parties les plus importantes de la conception initiale de go get était sa décentralisation : Google pensait alors (et l'équipe affirme encore y croire) que quiconque devrait pouvoir publier son code sur n'importe quel serveur, contrairement aux registres centraux tels que Perl. CPAN, Maven de Java ou Node NPM. En plaçant les noms de domaine au début de l'opération, l'espace d'importation a été réutilisé dans un système décentralisé existant et vous évitait de devoir résoudre à nouveau les problèmes de choix des utilisateurs. Cela permettait également aux entreprises d'importer du code sur des serveurs privés, parallèlement à du code provenant de serveurs publics. Il est essentiel de préserver cette décentralisation lorsque nous passons aux modules Go.
La décentralisation des dépendances de Go a eu de nombreux avantages, mais elle a également présenté quelques inconvénients importants. La première est qu’il est trop difficile de trouver tous les packages Go disponibles au public. Chaque site qui souhaite fournir des informations sur les packages doit effectuer sa propre analyse ou attendre que l'utilisateur lui pose des questions sur un package en particulier avant de le récupérer.
Aussi, l'équipe travaille sur un nouveau service : l'index de module Go, qui fournira un journal public des paquets entrant dans l'écosystème Go. Des sites tels que godoc.org et goreportcard.com pourront consulter ce journal pour rechercher de nouvelles entrées au lieu d'avoir à chaque fois du code implémenté indépendamment pour trouver de nouveaux packages. Google veut également que le service permette de rechercher des paquets à l’aide de requêtes simples, afin de permettre à goimports d’ajouter des importations pour les paquets qui n’ont pas encore été téléchargés sur le système local.
Authentification du module
Aujourd'hui, go get s'appuie sur une authentification au niveau de la connexion (HTTPS ou SSH) pour vérifier que le logiciel est en communication avec le bon serveur. Il n'y a pas de vérification supplémentaire du code lui-même, ce qui laisse ouverte la possibilité d'attaques par interférence si les mécanismes HTTPS ou SSH sont compromis d'une manière ou d'une autre. La décentralisation signifie que le code d'une build est extrait de nombreux serveurs différents, ce qui signifie que la build dépend de nombreux systèmes pour fournir le code correct.
La conception des modules Go améliore l'authentification du code en stockant un fichier go.sum dans chaque module ; ce fichier répertorie le hachage cryptographique de l’arborescence de fichiers attendue pour chacune des dépendances du module. Lorsque vous utilisez des modules, la commande go utilise go.sum pour vérifier que les dépendances sont identiques, octet par octet, aux versions attendues avant de les utiliser dans une build. Mais le fichier go.sum ne répertorie que les hachages correspondant aux dépendances spécifiques utilisées par ce module. Si vous ajoutez une nouvelle dépendance ou mettez à jour des dépendances avec go get -u, il n'y a pas d'entrée correspondante dans go.sum et donc pas d'authentification directe des octets téléchargés.
Pour les modules accessibles au public, Google prévoit d'exécuter un service appelé notaire, qui suit le journal d'index des modules, télécharge de nouveaux modules et signe de manière cryptographique les instructions de la forme « le module M de la version V contient un hachage H de l'arborescence de fichiers ». puis publie tous ces hachages répertoriés dans un journal inviolable de type certificat transparent de type interrogeable, de sorte que tout le monde puisse vérifier que le notaire se comporte correctement. Ce journal servira de fichier go.sum public et global que go get pourra utiliser pour authentifier les modules lors de l’ajout ou de la mise à jour de dépendances.
Citation:
Envoyé par Google
Nous souhaitons que la commande go vérifie les hachages notariés des modules accessibles au public qui ne sont pas déjà dans go.sum à partir de Go 1.13.
Miroirs de modules
Parce que le système décentralisé va chercher le code de plusieurs serveurs d'origine, le code de récupération est aussi rapide et fiable que le serveur le plus lent et le moins fiable. La seule défense disponible avant les modules concernait les dépendances des fournisseurs dans vos propres référentiels. Bien que ce système va continuer à être prise en charge, Google préfère une solution qui fonctionne pour tous les modules (pas seulement ceux que vous utilisez déjà) et qui ne nécessite pas de dupliquer une dépendance dans chaque référentiel qui l'utilise.
La conception du module Go introduit l'idée d'un module de proxy, qui est un serveur sur lequel la commande go demande des modules, au lieu des serveurs d'origine. Un type important de proxy est un miroir de module, qui répond aux demandes de modules en les extrayant des serveurs d'origine, puis en les mettant en cache pour les utiliser dans les futures demandes. Un miroir bien géré doit être rapide et fiable, même lorsque certains serveurs d'origine sont tombés en panne. Google prévoie de lancer un service miroir pour les modules accessibles au public en 2019.
Un des problèmes potentiels des miroirs est qu’ils sont précisément des serveurs intermédiaires, ce qui en fait une cible naturelle pour les attaques. Les développeurs de Go ont besoin d'une certaine assurance que les miroirs fournissent les mêmes octets que les serveurs d'origine. Le processus de notaire qui a été décrit dans la section précédente répond exactement à cette préoccupation et s’appliquera aux téléchargements utilisant des miroirs ainsi qu’aux téléchargements utilisant des serveurs d’origine.
Citation:
Envoyé par Equipe Go
Nous souhaitons que le miroir de module exécuté par Google soit prêt à être utilisé par défaut dans la commande go à partir de Go 1.13. L'utilisation d'un autre miroir, ou l'absence de miroir, sera facile à configurer.
Découverte de module
[QUOTE)Equipe Go]Enfin, nous avons mentionné plus tôt que l’index des modules facilitera la création de sites tels que godoc.org. Une partie de notre travail en 2019 consistera en une refonte majeure de godoc.org afin de le rendre plus utile pour les développeurs qui ont besoin de découvrir les modules disponibles, puis de décider de s’en remettre ou non à un module donné.[/QUOTE]
Résumé en diagramme
Source : blog Go
Et vous ?
:fleche: Qu'en pensez-vous ?
Voir aussi :
:fleche: L'équipe Go revient sur le processus de développement de la version 2.0 du langage et soumet des changements à venir dans Go 1.13
:fleche: Google annonce la sortie du runtime Go 1.11 sur App Engine, après la disponibilité de la nouvelle version de son langage
:fleche: L'équipe de Go publie des brouillons du design du langage Go 2, au menu : la généricité, la gestion des erreurs et la sémantique des valeurs d'erreur
:fleche: L'équipe en charge du développement de Go annonce la disponibilité de la version Go 1.11, qui s'accompagne d'un port expérimental pour WebAssembly
