2017-10-05 6 views
1

J'ai posté plusieurs bibliothèques java à Bintray, puis je les ai liées à Jcenter. Par souci d'argument, appelons l'une des bibliothèques 'my.private: repo'. Cela me permet d'utiliser la bibliothèque dans Gradle comme ceci:Jcenter lien vers un dépôt privé hébergé

... 
repositories { 
    jcenter() 
} 
... 
dependencies { 
... 
    implementation 'my.private:repo:1.0.0' 
... 
} 

Excellent. Maintenant, une crainte peut-être irrationnelle à mon avis est que j'atteindrai la limite de bande passante ou de stockage pour mes repos Bintray, et donc je devrai commencer à payer pour héberger les repos sur Bintray (actuellement j'ai 18 repos sur l'ouvert plan de source). Ma question est de savoir s'il est possible d'héberger les bibliothèques ailleurs (comme mon propre serveur privé), et que Jcenter fasse simplement la redirection. Je suis parfaitement conscient que je pouvais mettre en place un serveur privé et faire quelque chose comme ça ...

repositories { 
    jcenter() 
    maven { url ... } 
} 

Mais je ne veux vraiment pas faire. Je veux enlever autant de friction que possible du processus de construction ... ce qui signifie que je compte sur un seul serveur pour effectuer la redirection (comme un DNS), et un autre serveur pour faire l'hébergement réel.

Alors, est-il possible d'héberger les bibliothèques moi-même, et simplement Jcenter fait la redirection pour que je puisse rester avec le premier extrait de code?

Des idées? En passant, il semble qu'il serait judicieux de découpler les deux choses (redirection et hébergement), mais je comprends qu'il est plus rentable pour Bintray de les coupler puisqu'ils peuvent essentiellement forcer tout le monde qui sort du limites de mémoire ou de bande passante à payer (ce qu'ils ne pouvaient pas faire s'ils faisaient simplement la redirection).

Répondre

-1

Je ne suis pas un expert sur JCenter. Cependant, ils ne pourraient pas offrir une telle fonctionnalité pour les milliards de problèmes de sécurité que cela leur imposerait. Imaginez, vous seriez en mesure de devenir un «référentiel backend» pour JCenter (qui hébergerait lui-même des artefacts de maven). au cas où jcenter ne connaîtrait pas un artefact spécifique, il viendrait et vous poserait des questions à ce sujet. Ce serait un bon vecteur pour les fraudeurs de devenir un backend de jcenter et de publier des bibliothèques «patchées» contenant n'importe quel code malveillant. Dans ce cas, JCenter deviendrait distributeur d'artefacts modifiés (et potentiellement dangereux) de tiers.

La menace de sécurité existerait également si vous demandiez simplement une redirection vers une adresse spécifique. votre serveur pourrait encore être repris par des pirates et un pot modifié pourrait être publié. Dans les deux cas, il s'agirait de JCenter distribuant des fichiers jar éventuellement modifiés avec pratiquement aucun contrôle sur le contenu. Comme alternative - pensez à télécharger vos artefacts dans le travail de construction vers un référentiel maven plus durable - comme maven central.

+0

Je ne pense pas que ce soit une préoccupation valable. Jcenter pourrait imposer la contrainte qu'un seul site peut s'enregistrer pour distribuer un seul paquet (ils imposent déjà la contrainte que deux utilisateurs ne peuvent pas avoir de paquet avec le même nom de paquet). En outre, ils pourraient forcer les sites à vérifier leur légitimité en utilisant les clés GPG (qu'ils utilisent maintenant pour le téléchargement de toute façon). Donc, tout semble être en place pour eux de soutenir cela sans problèmes de sécurité. –