/cc @uranusjr @ncoghlan @altendky @njsmith

Je suis persuadé que c'est une chose qui se produit couramment (Corporate FW / proxy de mise en cache) - je pense que nous avons besoin d'un paramètre de remplacement pour spécifier un miroir à utiliser à la place de pypi si nous le trouvons dans le pipfile - comme PIPENV_PYPI_MIRROR ou PIPENV_PYPI_CACHING_PROXY ou quelque chose comme ça pour spécifier qu'il doit être essayé en premier, découpé en sources devant pypi essentiellement.

Cela semble-t-il atteindre l'objectif? Si c'est le cas, nous pouvons taguer dans le génie de l'implémentation pour nous dire pourquoi c'est bon ou mauvais (@ncoghlan)

Je commencerai par une mise en garde : jusqu'à ce que PyPI ait implémenté un mécanisme de signature de package similaire à PEP 458 pour fournir un moyen indépendant de TLS pour pip afin de garantir que les packages qui proviennent nominalement de PyPI correspondent réellement à ce que PyPI a publié , puis offrir la possibilité de rediriger le trafic de manière transparente vers un autre serveur est véritablement préoccupant du point de vue de la sécurité.

Malheureusement, ce vecteur d'attaque particulier est déjà ouvert via pip.conf , donc offrir quelque chose de comparable au niveau pipenv ne va rien aggraver.

Au-delà de cela, je pense qu'un mécanisme de réécriture d'URL de référentiel à usage général pourrait en fait être plus facile à documenter et à expliquer que quelque chose de spécifique à PyPI, du moins au niveau de la couche de capacité de base. Quelque chose comme:

pipenv --override-source-url 'default=https://pypi-proxy.example.com/api' --override-source-url 'https://pypi.python.org/simple=https://pypi-proxy.example.com/api'  --override-source-url 'https://pypi.org/simple=https://pypi-proxy.example.com/api' install

(Le seul bit spécifique à PyPI serait d'utiliser "default" pour faire référence à la source de téléchargement par défaut de pip, comme spécifié dans pip.conf ).

Épeler l'intégralité de la carte de remplacement de l'URL source à chaque fois serait difficile à utiliser dans la pratique, donc quelques options pour le sucre CLI pourraient ressembler à :

pipenv --override-source-urls <config file> install

pipenv --pypi-mirror https://pypi-proxy.example.com/api install

Que ce soit pour exposer ou non la couche --override-source-url immédiatement est une question différente - il pourrait être plus logique d'implémenter d'abord l'option --pypi-mirror plus simple, et de simplement garder la possibilité de --override-source-url et --override-source-urls comme options futures possibles à l'esprit tout en le faisant.

Un mappage général {given URL: override URL} a également été ma première pensée, mais après un examen plus approfondi, il existe des arguments en faveur d'une casse spéciale PyPI :

• PyPI est assez unique en ce qu'il a une URL publique bien connue et de nombreux miroirs

• PyPI a en fait plusieurs URL (par exemple, nous aurons probablement des Pipfiles flottant pendant un certain temps avec https://pypi.python.org/simple et https://pypi.org/simple , et peut-être aussi https://pypi.python.org/simple/ et https://pypi.org/simple/ avec la barre oblique finale ?), et ce serait bien si nous pouvions résoudre ce problème une fois au lieu de forcer chaque utilisateur à le découvrir lui-même

@njsmith Voir la suggestion de sucre --pypi-mirror <URL> dans la dernière partie de mon message - si la mise en œuvre initiale se concentrait uniquement sur cela, alors la capacité générale de réécriture d'URL pourrait commencer comme un détail de mise en œuvre interne (motivé par le fait que " PyPI" a plusieurs URL qui finissent toutes par se résoudre au même endroit), puis être considéré pour être exposé comme une fonctionnalité à part entière plus tard (après qu'il a été confirmé qu'il fonctionne comme souhaité pour l'utilisation principale --pypi-mirror Cas).

Ah d'accord, j'avais raté ça :-)

Existe-t-il une règle générale mappant les arguments de ligne de commande à une sorte de configuration plus persistante ? J'imagine que la plupart des utilisateurs de cela voudraient le configurer une fois, puis l'oublier.

@ncoghlan a écrit :

Je commencerai par une mise en garde : jusqu'à ce que PyPI ait implémenté un mécanisme de signature de package semblable à PEP 458 pour fournir un moyen indépendant de TLS pour que pip s'assure que les packages qui proviennent nominalement de PyPI correspondent réellement à ce que PyPI a publié, offrant alors la capacité rediriger le trafic de manière transparente vers un autre serveur est véritablement préoccupant du point de vue de la sécurité.

Si je lis correctement mon Pipfile.lock , il n'y a aucune relation stockée entre un paquet et la source à partir de laquelle il a été installé. Étant donné que l'ensemble de fonctionnalités existant permet de spécifier plusieurs sources, cela ne crée-t-il pas un problème similaire ? Un sync pourrait finir par obtenir un paquet d'une source différente de celle à laquelle il était habitué lors de la création du fichier de verrouillage.

Pipfile.lock stocke une liste de hachages d'artefacts acceptables pour chaque dépendance épinglée, donc une fois que vous avez effectué un verrouillage, il est difficile de remplacer subrepticement les packages. Au moment de la génération du verrou, s'inscrire explicitement à une source dans Pipfile signifie "Je fais confiance à cette source pour ne pas me déranger et j'utiliserai TLS pour vérifier que je parle réellement à ce point d'origine". (Je pense qu'il y a un problème quelque part sur la possibilité de lier des packages particuliers à des dépôts source particuliers, bien que cela puisse être dans pip ou l'un des autres dépôts PyPA, plutôt qu'ici)

La modification de l'URL d'index par défaut (ou l'ajout d'une URL d'index supplémentaire) dans pip.conf , ou l'utilisation de la fonctionnalité de remplacement proposée ici via un fichier de configuration ou un mécanisme basé sur un profil shell est différente : c'est-à-dire "je, ou un processus arbitraire je exécuté à un moment donné avec un accès en écriture à mon répertoire personnel (comme le fichier setup.py d'un sdist), a décidé de configurer mes paramètres pour faire confiance à cette source de packages". Et même un schéma de signature comme PEP 458 n'est pas une défense complète contre ce genre de manigances si les clés publiques utilisées pour la vérification sont elles-mêmes stockées quelque part dans votre répertoire personnel plutôt que dans un répertoire qui nécessite des privilèges élevés pour être modifié.

Il y a de bonnes raisons pour lesquelles les organisations ayant des exigences de sécurité strictes exécutent des builds sur des serveurs verrouillés avec un accès limité à Internet en général, ou surveillent ce type de problèmes au niveau du réseau :)

Notez également que si vous utilisez plusieurs index et qu'un paquet provient de l'index non primaire, cela sera indiqué dans le fichier de verrouillage.

Les préoccupations de pep 458 étaient essentiellement ce que j'avais à l'esprit, car les choses qui sont des URL différentes mais en réalité au point de pypi sont différentes que si vous venez de copier localement pypi et prétendez que c'est la même chose.

Moi, ou un processus arbitraire que j'ai exécuté à un moment donné avec un accès en écriture à mon répertoire personnel (comme le fichier setup.py d'un sdist), a décidé de configurer mes paramètres pour faire confiance à cette source de packages

S'il s'agit de votre modèle de menace, je ne vois pas comment tout ce que pipenv peut faire l'affectera beaucoup. Quelqu'un qui peut modifier la configuration de votre répertoire personnel peut également faire des choses comme insérer un nouveau répertoire sur $PATH et y insérer un faux pipenv qui fait ce qu'il veut.

@njsmith c'est aussi le modèle de menace de pip, car l'installation du package nécessite l'exécution de code arbitraire à partir des fichiers sdist setup.py . Ce code pourrait en effet écraser des éléments de votre répertoire personnel, tels que vos paramètres, ou ajouter des éléments à votre chemin, ou un certain nombre de choses. C'est pourquoi privilégier explicitement pypi (un index connu et fiable) et exiger la vérification du hachage est un bon pas vers la sécurité. Il permet un contrôle centralisé et l'élimination des menaces de sécurité connues et identifie la vérification des packages que vous téléchargez de manière distribuée. Que dit le fichier de verrouillage que vous avez téléchargé à propos du hachage que vous devriez obtenir ? Cela ne correspond pas à ce que vous obtenez de l'index ? Pour que ce mode de fonctionnement échoue, vous devez avoir des échecs sur plusieurs machines locales, index et couche réseau, car vous parlez d'avoir plusieurs packages corrompus dans votre pile d'applications travaillant de concert pour vérifier les hachages par rapport à un index de confiance. , et dans de nombreux cas, les hachages eux-mêmes provenaient d'une autre source non impliquée. Alors maintenant, vous devez avoir au minimum, toutes les vérifications de hachage dans pip et pipenv falsifiées d'une manière ou d'une autre de sorte qu'elles génèrent des hachages identiques à ceux que vous espérez, mais installent encore d'autres choses malveillantes ?

Je suppose que ce que je dis, c'est que si votre machine locale est compromise, rien de pip ou de pipenv ne fera pour vous sauver. Mais nous pouvons nous assurer que le package que vous téléchargez est celui que vous recherchiez, à partir de l'endroit où vous étiez censé le rechercher, ce qui peut fournir un élément de la chaîne de sécurité.

@ncoghlan @njsmith comment tout cela est-il pris en compte avec le mouvement de repousser sudo pip install... et le sens général, je pense que nous avons tous que si vous allez utiliser pip, vous ne devriez probablement pas aussi utiliser votre gestionnaire de paquets système pour installer les choses python au sens large. Ce n'est peut-être pas vraiment une question de pipenv, mais c'est là où en est la discussion en ce moment et cela pourrait guider les prochaines étapes...

@techalchemy Je ne vois aucun lien avec ce sujet ? Je pense que la conclusion de tout ce qui précède est que laisser les utilisateurs remplacer le miroir que pipenv utilise pour PyPI n'introduit aucune menace supplémentaire, et faire sudo pipenv n'a même pas de sens en premier lieu, n'est-ce pas ?

@njsmith non, je ne pense pas que quiconque devrait utiliser sudo pipenv , comme je l'ai mentionné, ce n'est pas vraiment sur le sujet, mais comme nous avons un peu parcouru le chemin du modèle de menace, j'ai pensé que cela valait la peine d'être exploré. Spécifiquement:

Et même un schéma de signature comme PEP 458 n'est pas une défense complète contre ce genre de manigances si les clés publiques utilisées pour la vérification sont elles-mêmes stockées quelque part dans votre répertoire personnel plutôt que dans un répertoire qui nécessite des privilèges élevés pour être modifié.
Il y a de bonnes raisons pour lesquelles les organisations ayant des exigences de sécurité strictes exécutent des builds sur des serveurs verrouillés avec un accès limité à Internet en général, ou surveillent ce type de problèmes au niveau du réseau :)

Si une défense, au moins dans une certaine mesure, repose sur le stockage de clés dans un emplacement privilégié, mais que nous vous déconseillons d'utiliser des installations python privilégiées, je pense que cela vaut peut-être la peine d'en discuter. J'ai peut-être tort. Mais cela semble définitivement lié au commentaire de @ncoghlan (mais pas sudo pipenv , cela ne devrait jamais être une chose)

Oui, cela semblait probablement sorti de nulle part, juste une pensée aléatoire. Espérons que le contexte supplémentaire clarifie certains

Je vote pour que nous gardions ce problème sur le thème de l'aide aux personnes qui ont besoin d'utiliser des miroirs PyPI, plutôt que de nous lancer dans une discussion spéculative sur la manière dont nous pourrions implémenter TUF. (Quoi qu'il en soit, je ne pense pas que nous puissions ou devrions faire grand-chose pour essayer de nous défendre contre un attaquant qui a un accès arbitraire en écriture au répertoire personnel de l'utilisateur.)

D'accord, définissons donc le comportement que nous attendrions ou préférerions. Ma compréhension de travail actuelle est que :

• Si --pypi-mirror est passé ou si PIPENV_PYPI_MIRROR est défini, nous devrions préférer que
• Doit-on le préférer à PyPI uniquement ? Comment évaluons-nous si une URL d'index donnée est "PyPI" ? Nous ne pouvons pas l'interroger, nous devrions donc maintenir une liste
• La liste devrait-elle contenir toutes les permutations possibles, ou devrions-nous nous contenter d'utiliser les deux URL que nous avons utilisées dans le passé pour générer des Pipfiles comme les choses pour lesquelles nous devrions d'abord essayer le miroir fourni ?

Il ne doit remplacer que PyPI, pas les autres URL. Je suppose qu'il n'y a probablement que quelques URL PyPI différentes utilisées, donc elles peuvent être répertoriées, et si nous en manquons une, quelqu'un signalera un bogue, il sera ajouté, et bientôt nous les aurons toutes.

Cela me semble être la bonne approche.

Ce que @njsmith a dit correspond également à mon point de vue. Les 3 URL de dépôt que je suggérerais de remplacer dans un PR initial seraient :

• Aucun défini (c'est-à-dire en s'appuyant sur le paramètre par défaut de pip )
• https://pypi.python.org/simple
• https://pypi.org/simple

La barre oblique ou non finale est probablement mieux gérée comme une étape de normalisation d'URL, plutôt qu'en répertoriant les URL séparément.

Notez que les requêtes Pipfile ont une barre oblique finale (au moment de la rédaction) , nous devons donc probablement gérer cela d'une manière ou d'une autre.

C'est vrai, ma pensée était :

• maintenir une liste d'URL sans barres obliques à la fin
• vérifier les URL entrantes pour une barre oblique finale et la supprimer si elle est trouvée ( str.rstrip serait probablement assez bon pour la tâche, même si cela supprimerait un nombre arbitraire de barres obliques finales, sinon nous pourrions être plus stricts à ce sujet, et supprimer au plus une barre oblique finale)

Impressionnant. Je pense que c'est suffisant pour travailler avec et assez simple à construire. Merci a tous!

J'espère que la fonction miroir pourrait être ajoutée bientôt ~

Je rencontre également ce problème. La situation est :

• Avoir un serveur PyPI interne avec des packages privés.
• Avoir plusieurs applications Python qui utilisent Pipenv pour gérer leurs dépendances.
• Certaines des dépendances résident sur le serveur PyPI interne et d'autres sur le PyPI communautaire. L'interne redirige vers la communauté PyPI pour tout paquet introuvable.

Ma stratégie de déploiement configure déjà un pip.conf à l'échelle du système qui fait référence au serveur PyPI interne. Étonnamment, j'ai constaté que cette configuration est ignorée par Pipenv.

Je remarque que si je devais déplacer/renommer le PyPI interne, plusieurs applications avec Pipfiles devraient être mises à jour et leurs fichiers Pipfile.lock régénérés. Une option miroir fournirait la fonctionnalité souhaitée. Cela fonctionnerait également et semblerait moins redondant si Pipenv pouvait simplement lire la configuration système pour Pip.

PRs bienvenus sur celui-ci btw

Salut. J'ai le même besoin mais je diviserais cette fonctionnalité de remplacement dans un autre ticket.

Voici ma proposition de comportement attendu :

• un fichier de configuration peut être défini pour définir chaque valeur définie dans la section [[source]] du Pipfile.
• pourrait être un fichier toml avec seulement la section [[source]] du Pipfile
• L'emplacement de ce fichier est fortement inspiré des règles définies pour pip.conf (ex : /etc/pipenrc.toml, ~/.pipenvrc.toml
• des variables environ pourraient également être définies pour remplacer ces valeurs (rappel : nous avons besoin de toutes les valeurs de [[source]]). À définir
• le comportement actuel de pipenv est maintenant :
  
  
  
  • lors de la création d'un Pipfile, il reprend les valeurs du fichier de configuration / variable d'environnement
  
  
  • si aucun fichier de configuration ou variable d'environnement n'est défini, le comportement actuel de pipenv s'applique
  
  
  • pipenv continue de toujours générer la section [[source]] du Pipfile
  
  
  • si une section [[source]] du Pipfile existe, pipenv n'essaie pas de remplacer quoi que ce soit avec les valeurs du fichier de configuration.
  
  

Et dans un second ticket, les options —override peuvent être implémentées. Cela a du sens par exemple à l'intérieur d'un CI ou quelque chose.

En passant: nous utilisons beaucoup pipenv en production maintenant, mais je dois rappeler trop souvent à tout le monde qu'ils doivent changer leur Pipfile manuellement lorsqu'ils démarrent un nouveau projet pour accéder à notre référentiel Arrifactory Pypi (pour information, Nexus fait également un Pypi cache gratuitement et t fonctionne très bien !). Nous avons un pare-feu très limité et c'est une très bonne pratique au sein d'une entreprise de mettre en cache les dépendances externes, afin qu'elles puissent être sauvegardées et vérifiées pour les vulnérabilités par exemple.
Si une simple fonctionnalité similaire au fichier de configuration générale ou utilisateur (comme on le fait déjà pour pip ou npm), pour qu'on la déploie sur tout notre poste de travail pour que nos développeurs fassent moins d'erreurs, ce serait parfait pour moi)

Peut-être que j'ai raté quelque chose, mais cela ressemble à une régression. Nous sommes sur 11.6.0 depuis un moment et pipenv a joyeusement délégué les paramètres de notre pip.conf, qui pointent vers un miroir pypi interne.

Une idée de quand cela s'est cassé? Cela rend pipenv complètement inutilisable dans notre contexte. J'ai du mal à voir cela comme une "fonctionnalité manquante" alors que cela fonctionnait apparemment bien depuis longtemps.

Pour être clair : après la mise à niveau vers 2018.05.18, même avec le miroir spécifié dans notre Pipfile[.lock], pipenv essaie d'installer de nouveaux packages à partir de pypi.org.

Peut-être que ce que je vois est un problème distinct de celui-ci...

@brettdh C'est difficile à dire sans voir votre environnement, mais je pense que ce n'est pas le même problème. Je vous suggère de faire une bissection entre les versions pour voir exactement où cela a changé et d'ouvrir un nouveau problème pour cela.

Je travaille sur le PR pour ça.

Je pense que cela a été régressé par rapport au réglage par défaut. Il a peut-être été pris dans une vague de mises à jour pour pip 10 qui ne sont pas encore publiées, mais je pense que nous pouvons le récupérer sans trop de difficulté si @JacobHenner ne l'ajoute pas déjà

Je suppose que vous parlez d'utiliser devpi comme proxy de mise en cache pour PyPi officiel. Pour pip lui-même, vous devrez modifier /etc/pip.conf et /usr/lib64/python3.6/disutils/distutils.cfg pour que pip utilise votre serveur devpi local pour toutes les requêtes.

Cependant, il semble que pipenv ignore ces paramètres à l'échelle du système, vous êtes donc obligé de modifier le paramètre de configuration [[source]] dans Pipfile pour référencer votre serveur devpi. Mais si vous publiez votre Pipfile en externe, les contributeurs externes doivent supprimer vos paramètres [[source]] pour créer leur propre environnement.

Je pense que pipenv devrait simplement respecter les paramètres globaux de /etc/pip.conf et /usr/lib.../distutils.cfg

@polski-g

Je suppose que vous parlez d'utiliser devpi comme proxy de mise en cache pour PyPi officiel

Nexus Repository, mais oui, même idée.

Cependant, il semble que pipenv ignore ces paramètres à l'échelle du système

Comme @techalchemy l'a mentionné, je crois que pipenv (11.6.0) respectait pip.conf (homedir également), mais la dernière version ne le fait pas - en particulier, il y a une URL pypi.org codée en dur quelque part (dépendance résolution, IIRC) qui ne peut pas être outrepassé.

Je pense que pipenv devrait juste respecter les paramètres globaux de /etc/pip.conf et /usr/lib.../distutils.cfg

D'accord - bien que personnellement, je n'ai pas eu à modifier distutils.cfg dans mon cas d'utilisation.

IIRC il y avait une résolution pour ne pas respecter pip.conf, mais vous devrez creuser profondément dans le suivi des problèmes pour le trouver. Dans tous les cas, le navire a navigué, et avec la mise en miroir PyPI presque terminée, il est peu probable que cela change dans un avenir proche.

Je suis assez confiant que cette fonctionnalité sera livrée dans la prochaine version (qui sera livrée dans un jour ou deux avec de la chance)

De plus, je ne suis pas sûr de cela, mais il est possible que nous devions simplement appeler .load() après avoir créé l'analyseur de configuration ici pour obtenir les valeurs par défaut de la configuration.

https://github.com/pypa/pipenv/blob/master/pipenv/project.py#L573 -#L577

@uranusjr tant que la configuration de la mise en miroir fonctionne (c'est-à-dire n'utilise pas l'URL pypi.org codée en dur que j'ai mentionnée), je ne vois aucun problème à ce que pipenv ait sa propre configuration pour cela et ignore les pip.

@brettdh Pourriez-vous vérifier ma succursale et confirmer qu'elle répond à vos
cas d'utilisation dans votre environnement ?

>

@JacobHenner oui , merci. Mon test initial avec l'option --pypi-mirror ( pipenv install , pipenv lock ) semble fonctionner correctement. J'ai laissé une petite suggestion sur le PR.

Je suis un peu inquiet, cependant, que les URL codées en dur vers pypi.org apparaissent toujours dispersées dans les sources pipenv. Je ne peux pas être sûr de ceux qui sont correctement remplacés par les entrées [[source]] , et je ne me souviens pas exactement quel flux de travail a causé mon problème ci-dessus. Il est donc difficile de dire si c'est réparé. 😬

Oui, après cette version, je prévois un nettoyage majeur du code. Les trucs Cli se déplacent vers le cli, bouillonnent les exceptions là-bas et gèrent toutes les sorties là-bas, déduisent le code dupliqué, etc. Ça va être beaucoup de travail et l'aide sera appréciée si quelqu'un veut se porter volontaire :p

Je viens de tirer la version récente et il est toujours en train de coder en dur le pypi.org dans les sources. Le but est-il de prendre la variable d'environnement ou le pypi-mirror et de le mettre par défaut pour [[source]] ?

Éditer:

Je viens de creuser dans le code. On dirait que vous avez

if PIPENV_TEST_INDEX:
    DEFAULT_SOURCE = {
        u"url": PIPENV_TEST_INDEX,
        u"verify_ssl": True,
        u"name": u"custom",
    }
else:
    DEFAULT_SOURCE = {
        u"url": u"https://pypi.org/simple",
        u"verify_ssl": True,
        u"name": u"pypi",
    }

Je pense que si vous changiez cela Si PIPENV_TEST_INDEX à la variable d'environnement PIPENV_PYPI_MIRROR ce serait un bon début

La solution discutée ici a longtemps été mise en œuvre. L'extrait que vous avez cité est un extrait par défaut , c'est-à-dire utilisé si vous ne fournissez pas de source lors de la création du Pipfile.

Non, la source ne doit pas changer dans le Pipfile. Le but de ce changement
était de permettre aux utilisateurs de remplacer les URL PyPI par un miroir, _sans_ changer
le Pipfile.

@JacobHenner Le code de gestion du miroir post-traite la liste source et remplace les URL pypi.org par des références au miroir spécifié.

C'est ce qui permet au remplacement du miroir de fonctionner même s'il y a une entrée pypi.org explicite dans Pipfile . pipenv s'appuie ensuite sur cette même logique pour remplacer également sa propre source par défaut.

S'il existe actuellement des cas où ce post-traitement n'est pas appliqué correctement, il s'agit d'un nouveau rapport de bogue sur la fonctionnalité déjà implémentée, plutôt que d'une demande de fonctionnalité.

Je pense que ce dernier commentaire était destiné à @kylecribbs ?

@JacobHenner Ah, désolé - j'ai mal interprété votre commentaire comme disant que ce changement n'avait pas atteint son objectif initial, plutôt que comme une réponse à Kyle qui visait à clarifier ce qu'était réellement ce résultat.