# JFrog arrête Bintray/JCenter
par Thomas Broyer
À la surprise générale, JFrog a annoncé l’arrêt des services Bintray, JCenter, GoCenter et ChartCenter dès le mois de mai. Si GoCenter et ChartCenter sont assez confidentiels, Bintray/JCenter est un composant essentiel pour les développeurs Groovy (la résolution de dépendances via Grape utilise JCenter par défaut, et le projet utilise Bintray pour distribuer ses releases et snapshots) et Android (une dépendance de l’Android Gradle Plugin est disponible uniquement sur JCenter), et dans une moindre mesure pour tous les utilisateurs de Gradle (le Gradle Plugin Portal délègue aujourd’hui à JCenter pour les dépendances transitives des plugins).
Après une période d’affolement toute légitime, JFrog a précisé que si le déploiement de nouvelles versions ne serait plus possible au 1er mai, le repository resterait disponible en lecture seule jusqu’au début de l’année prochaine, le temps que tout le monde s’organise.
De son côté, Sonatype, qui gère le Central Repository, propose son aide pour migrer de JCenter vers Central; et Gradle a publié un article détaillé sur la marche à suivre pour migrer ses projets en toute sécurité.
# [Infographie] PostgreSQL
par Charles-Henry Vagner, Aurélien Morlé et Jean-Philippe Thevenoux
Chaque mois, nous publions une infographie sur notre site Internet et sur notre blog. Ce mois-ci, nous avons choisi une technologie que nous aimons tout particulièrement chez Atol CD : PostgreSQL ! Retrouvez dans cette infographie quelques caractéristiques techniques, des chiffres-clé, son histoire mais aussi pourquoi nous l’aimons et notre Top5 des fonctionnalités côté développement.
# La sécurité de la chaîne logistique logicielle à nouveau sous les projecteurs
par Thomas Broyer
Un chercheur en sécurité met à nouveau le doigt sur une vulnérabilité de nos chaînes logistiques, à savoir nos repositories de dépendances tierces, lorsque des entreprises utilisent des dépôts internes pour y publier également des dépendances privées. S’il a été démontré ici avec NPM, PyPI et RubyGems, le problème s’applique plus largement à la plupart des écosystèmes utilisant un registre central et des identifiants sans espace de nommage, comme le souligne Sonatype.
La solution ici est donc d’utiliser des espaces de nommage pour toutes les dépendances privées. Mais ça n’est pas suffisant, car il reste la possibilité du brandsquatting : l’attaquant pouvant utiliser le même espace de nommage sur le registre public, il faut donc aussi le réserver, même s’il est généralement possible d’utiliser des règles au niveau du proxy pour conserver ces espaces de nommage privé et ainsi éviter toute confusion. GitHub a publié sur son blog plus de détails sur la marche à suivre concernant NPM.
À noter qu’une problématique un peu différente touche aussi les écosystèmes où il est assez courant d’utiliser plusieurs dépôts de dépendances, comme Maven. Gradle permet d’appliquer des filtres lors de la déclaration des dépôts dans ses projets, et des repository managers, comme Nexus ou Artifactory, permettent de définir des filtres de la même manière. L’idée est que chaque dépôt spécifique est responsable d’un espace de nommage en particulier, pour éviter des confusions de dépendances comme on a pu en voir sur JCenter il y a quelques années à cause d’un défaut de validation du propriétaire de l’espace de nom, un problème qu’on pourrait rencontrer à l’inverse avec les utilisateurs migrant vers Central depuis JCenter suite à l’arrêt de ce dernier, Bintray et Central n’ayant pas les mêmes règles de validation (les utilisateurs de Gradle pourront utiliser la vérification des dépendances pour s’assurer d’utiliser les mêmes artefacts lors de la bascule).
Laisser un commentaire