/ cc @uranusjr @ncoghlan @altendky @njsmith

これは一般的に発生することであると私は確信しています（企業のFW /キャッシングプロキシ）-pipfileで見つかった場合、pypiの代わりに使用するミラーを指定するためのオーバーライド設定が必要だと思います- PIPENV_PYPI_MIRRORまたはPIPENV_PYPI_CACHING_PROXYなど、最初に試す必要があることを指定し、基本的にpypiの前でsourcesにスライスします。

それは目標を達成しているように見えますか？ もしそうなら、実装の魔神にタグを付けて、これが良いか悪いかを教えてください（@ncoghlan）

注意点から始めます。PyPIがPEP458に類似したパッケージ署名メカニズムを実装してpipにTLSに依存しない方法を提供し、名目上PyPIから発信されたパッケージが実際にPyPIが公開したものと一致するようにするまで、次に、トラフィックを別のサーバーに透過的にリダイレクトする機能を提供することは、セキュリティの観点から真に懸念されます。

残念ながら、その特定の攻撃ベクトルはすでにpip.confを介して開かれているため、 pipenvレベルで同等のものを提供しても、これまで以上に悪化することはありません。

それを超えて、汎用リポジトリのURL書き換えメカニズムは、少なくとも基本機能層では、PyPI固有のものよりも実際に文書化して説明する方が簡単だと思います。 何かのようなもの：

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

（PyPI固有のビットは、 pip.confで指定されているように、「default」を使用してpipのデフォルトのダウンロードソースを参照することだけです）。

ただし、ソースURLオーバーライドマップ全体を毎回スペルアウトすると、実際に使用するのは扱いにくいため、CLIシュガーのいくつかのオプションは次のようになります。

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

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

--override-source-urlレイヤーをすぐに公開するかどうかは別の質問です。最初に、より単純な--pypi-mirrorオプションを実装し、単に--override-source-urlの可能性を維持する方が理にかなっているかもしれません。そうしている間、可能な限り将来のオプションを念頭に置いて--override-source-urls 。

一般的な{given URL: override URL}マッピングも私の最初の考えでしたが、さらに検討すると、特殊なケーシングのPyPIにはいくつかの議論があります。

• PyPIは、よく知られているパブリックURLと多数のミラーを備えているという点で非常にユニークです。

• PyPIには実際には複数のURLがあります（たとえば、 https://pypi.python.org/simpleとhttps://pypi.org/simpleの両方、さらにはhttps://pypi.python.org/simple/とhttps://pypi.org/simple/のPipfileがしばらくの間浮かんでいる可能性があります

@njsmith私の投稿の最後の部分にある--pypi-mirror <URL>の砂糖の提案を参照してください-最初の実装がそれだけに焦点を当てている場合、一般的なURL書き換え機能は、内部実装の詳細として開始できます（「 PyPI "には複数のURLがあり、それらはすべて最終的に同じ場所に解決されます）、その後すぐに（主要な--pypi-mirrorの使用で希望どおりに機能していることが確認された後）、それ自体が機能として公開されると見なされます場合）。

ああ、そうだ、私はそれを逃した:-)

コマンドライン引数をある種のより永続的な構成にマッピングする一般的なルールはありますか？ これのほとんどのユーザーは、一度設定してから忘れたいと思うでしょう。

@ncoghlanは書いた：

注意点から始めましょう：PyPIがPEP 458に似たパッケージ署名メカニズムを実装して、名目上PyPIから発信されたパッケージが実際にPyPIが公開したものと一致することを保証するために、TLSに依存しない方法をpipに提供するまで、トラフィックを別のサーバーに透過的にリダイレクトすることは、セキュリティの観点から真に懸念されています。

Pipfile.lockを正しく読んでいる場合、パッケージとそれがインストールされたソースとの間に保存された関係はありません。 既存の機能セットで複数のソースを指定できるとすると、同様の問題が発生しませんか？ syncは、ロックファイルの作成時に使用されたものとは異なるソースからパッケージを取得することになる可能性があります。

Pipfile.lockは、固定された依存関係ごとに受け入れ可能なアーティファクトハッシュのリストを格納するため、ロックを実行すると、パッケージを密かに置き換えることは困難です。 ロックの生成時に、 Pipfileのソースに明示的にオプトインすると、「このソースが混乱しないように信頼し、TLSを使用して実際にこの起点と話していることを確認します」と言っています。 （ここではなく、 pipまたは他のPyPAリポジトリのいずれかにある可能性がありますが、特定のパッケージを特定のソースリポジトリにバインドする可能性について議論している問題があると思います）

pip.confでデフォルトのインデックスURLを変更する（または追加のインデックスURLを追加する）か、構成ファイルまたはシェルプロファイルベースのメカニズムを介してここで提案されているオーバーライド機能を使用することは異なります。ある時点で、ホームディレクトリ（sdistのsetup.pyファイルなど）への書き込みアクセス権を使用して実行され、このパッケージのソースを信頼するように設定を構成することにしました。 また、PEP 458のような署名スキームでさえ、検証に使用される公開鍵自体が、変更するために昇格された特権を必要とするディレクトリではなく、ホームディレクトリ内のどこかに格納されている場合、これらの種類のシェナニガンに対する完全な防御にはなりません。

厳格なセキュリティ要件を持つ組織が、インターネットへのアクセスが制限されたロックダウンされたサーバーでビルドを実行する、またはネットワークレベルでこの種の問題を監視するのには十分な理由があります:)

複数のインデックスを使用していて、パッケージが非プライマリインデックスからのものである場合も、ロックファイルに示されることに注意してください。

pep 458の懸念は、基本的に私が念頭に置いていたものでした。URLは異なりますが、実際にはpypiのポイントは、ローカルでpypiをコピーして同じであると主張した場合とは異なります。

私、またはホームディレクトリへの書き込みアクセス権を使用してある時点で実行した任意のプロセス（sdistのsetup.pyファイルなど）は、このパッケージのソースを信頼するように設定を構成することにしました。

これがあなたの脅威モデルである場合、pipenvがどのようにそれを実行できるかはわかりません。 ホームディレクトリの設定を変更できる人は、 $PATHに新しいディレクトリを挿入し、そこに偽のpipenvを挿入して、好きなことを実行することもできます。

@njsmithこれはpipの脅威モデルでもあります。これは、パッケージのインストールにはsdist setup.pyファイルからの任意のコードの実行が許可されているためです。 そのコードは確かに、設定などのホームディレクトリ内のものを上書きしたり、パスに何かを追加したりする可能性があります。 そのため、明示的にpypi（既知の信頼できるインデックス）を特権化し、ハッシュチェックを要求することは、セキュリティに向けた良いステップです。 これにより、既知のセキュリティ脅威を集中管理および排除し、ダウンロードしているパッケージの検証を分散して識別できます。 ダウンロードしたロックファイルは、取得する必要のあるハッシュについて何と言っていますか？ インデックスから取得しているものと一致しませんか？ この動作モードが失敗するためには、複数のローカルマシン、インデックス、およびネットワーク層で障害が発生する必要があります。これは、アプリケーションスタック内の複数の破損したパッケージが連携して動作し、信頼できるインデックスに対してハッシュを検証することについて話しているためです。 、そして多くの場合、ハッシュ自体はさらに別の関与していないソースから来ました。 だから今、あなたは少なくとも、pipとpipenvの両方のハッシュチェックのすべてが、あなたが望んでいるものと同じハッシュを生成するように何らかの形で改ざんされている必要がありますが、さらに他の悪意のあるものをインストールしますか？

私が言っているのは、ローカルマシンが危険にさらされた場合、pipやpipenvがあなたを救うために何もすることはないということだと思います。 ただし、ダウンロードするパッケージが、検索するはずの場所から探しているものであることを確認できます。これにより、セキュリティチェーンの1つの要素を提供できます。

@ncoghlan @njsmithこれは、 sudo pip install...に反対する動きと、一般的な意味でどのように考慮されますか。pipを使用する場合は、おそらく大まかに言えば、Pythonのものをインストールするシステムパッケージマネージャー。 これは実際にはpipenvの質問ではないかもしれませんが、それは現在議論が行われている場所であり、これが次のステップを導くかもしれません...

@techalchemyこのトピックとの関連性はまったくわかりませんか？ 上記のすべての結論は、ユーザーがPyPIに使用するミラーpipenvをオーバーライドできるようにしても、追加の脅威は発生しないと思います。また、 sudo pipenvを実行しても、そもそも意味がありません。

@njsmithいいえ私は誰もsudo pipenvを使うべきではないと思います。私が言ったように、それは実際には話題ではありませんが、脅威モデルの道を少し進んだので、調査する価値があると思いました。 具体的には：

また、PEP 458のような署名スキームでさえ、検証に使用される公開鍵自体が、変更するために昇格された特権を必要とするディレクトリではなく、ホームディレクトリ内のどこかに格納されている場合、これらの種類のシェナニガンに対する完全な防御にはなりません。
厳格なセキュリティ要件を持つ組織が、インターネットへのアクセスが制限されたロックダウンされたサーバーでビルドを実行する、またはネットワークレベルでこの種の問題を監視するのには十分な理由があります:)

少なくともある程度の防御が特権のある場所に保存されているキーに依存しているが、特権のあるpythonインストールを使用しないようにアドバイスしている場合は、議論する価値があると思います。 たぶん私は間違っています。 しかし、それは間違いなく@ncoghlanのコメントに関連しているようです（ただし、 sudo pipenvではなく、決して問題になることはありません）

ええ、それはおそらくどこからともなく出てきたように見えました、ただランダムな考えです。 うまくいけば、追加のコンテキストがそれをいくつかクリアします

私は、TUFをどのように実装するかについての投機的な議論に入るのではなく、PyPIミラーを使用する必要がある人々を支援するというトピックでこの問題を維持することに投票します。 （とにかく、ユーザーのホームディレクトリへの任意の書き込みアクセス権を持つ攻撃者から防御するためにできることやすべきことはあまりないと思います。）

さて、それでは、私たちが期待または好む動作を定義しましょう。 私の現在の実用的な理解は次のとおりです。

• --pypi-mirrorが渡された場合、またはPIPENV_PYPI_MIRRORが設定されている場合は、
• PyPIのみよりも優先する必要がありますか？ 特定のインデックスURLが「PyPI」であるかどうかをどのように評価していますか？クエリを実行できないため、リストを維持する必要があります
• リストにすべての可能な順列を含める必要がありますか、それとも、提供されたミラーを最初に試す必要があるものとしてPipfileを生成するために過去に使用した2つのURLを使用することに満足する必要がありますか？

他のURLではなく、PyPIのみをオーバーライドする必要があります。 おそらく使用されているPyPIURLは数種類しかないので、リストに載せることができます。1つを見逃すと、誰かがバグを報告して追加され、まもなくすべてのURLが追加されます。

私にとって正しいアプローチのようです。

@njsmithが言ったことは、私の見方にも一致します。 最初のPRで置き換えることをお勧めする3つのリポジトリURLは次のとおりです。

• 設定なし（つまり、 pipのデフォルト設定に依存する場合）
• https://pypi.python.org/simple
• https://pypi.org/simple

末尾のスラッシュかどうかは、URLを個別にリストするよりも、URL正規化ステップとして処理する方が適切な場合があります。

リクエストのPipfileには（執筆時点で）末尾にスラッシュがあることに注意してください。したがって、おそらくこれを何らかの方法で処理する必要があります。

そうです、私の考えは次のとおりです。

• 末尾にスラッシュを付けずにURLのリストを維持する
• 受信URLで末尾のスラッシュを確認し、見つかった場合は削除します（ str.rstripは、任意の数の末尾のスラッシュを削除する場合でも、タスクには十分である可能性があります。そうでない場合は、より厳密にすることができます。末尾のスラッシュを最大1つ削除します）

素晴らしい。 これで十分に機能し、シンプルに構築できると思います。 皆さんありがとう！

ミラー機能がすぐに追加されることを願っています〜

私もこの問題に直面しています。 状況は次のとおりです。

• いくつかのプライベートパッケージを備えた内部PyPIサーバーがあります。
• Pipenvを使用して依存関係を管理する複数のPythonアプリケーションがあります。
• 一部の依存関係は内部PyPIサーバーに存在し、その他の依存関係はコミュニティPyPIに存在します。 内部のものは、パッケージが見つからない場合はコミュニティPyPIにリダイレクトします。

私のデプロイメント戦略では、内部PyPIサーバーを参照するシステム全体のpip.confがすでに設定されています。 驚いたことに、この構成はPipenvによって無視されていることがわかりました。

内部PyPIを移動/名前変更する場合、Pipfilesを使用するいくつかのアプリケーションを更新し、それらのPipfile.lockファイルを再生成する必要があることに気づきました。 ミラーオプションは、必要な機能を提供します。 PipenvがPipのシステム構成を読み取ることができれば、それも機能し、冗長性が少なくなります。

PRはこれを歓迎します

こんにちは。 同じニーズがありますが、このオーバーライド機能を別のチケットに分割します。

これが私の予想される行動の提案です：

• Pipfileの[[source]]セクションで定義されたすべての値を設定するように構成ファイルを定義できます。
• Pipfileの[[source]]セクションのみを含むtomlファイルである可能性があります
• このファイルの場所は、pip.conf用に定義されたルール（例：/etc/pipenrc.toml、~/.pipenvrc.toml）に大きく影響されています。
• environ変数を定義して、これらの値をオーバーライドすることもできます（注意：[[source]]のすべての値が必要です）。 定義します
• pipenvの現在の動作は次のとおりです。
  
  
  
  • Pipfileを作成するとき、構成ファイル/環境変数から値を取得します
  
  
  • 構成ファイルまたは環境変数が定義されていない場合、pipenvの現在の動作が適用されます
  
  
  • pipenvは、Pipfileの[[source]]セクションを常に生成し続けます
  
  
  • Pipfileの[[source]]セクションが存在する場合、pipenvは構成ファイルの値で何もオーバーライドしようとしません。
  
  

また、2番目のチケットでは、オーバーライドオプションを実装できます。 たとえば、CIなどの内部で意味があります。

補足：現在、本番環境ではpipenvを多用していますが、Arrifactory Pypiリポジトリにアクセスするために新しいプロジェクトを開始するときにPipfileを手動で変更する必要があることを、頻繁に思い出させる必要があります（詳細については、NexusはPypiも実行します）無料でキャッシュし、tはうまく機能します！）。 ファイアウォールは非常に制限されており、企業内では外部の依存関係をキャッシュすることをお勧めします。これにより、たとえば、バックアップして脆弱性をチェックできます。
一般構成ファイルまたはユーザー構成ファイルに似た単純な機能（すでにpipまたはnpmに対して行っているような）で、開発者がミスを少なくするようにすべてのワークステーションにデプロイする場合、それは私にとって完璧です）

何かを逃したかもしれませんが、これは退行のようです。 私たちはしばらくの間11.6.0を使用しており、pipenvは内部のpypiミラーを指すpip.confの設定に喜んで委任しました。

これが壊れたときのアイデアはありますか？ これにより、pipenvは私たちのコンテキストでは完全に使用できなくなります。 どうやら長い間正常に機能していたのに、これを「欠落している機能」と見なすのに苦労しています。

明確にするために：2018.05.18にアップグレードした後、Pipfile [.lock]で指定されたミラーを使用しても、pipenvはpypi.orgから新しいパッケージをインストールしようとします。

多分私が見ているのはこれとは別の問題です...

@brettdhあなたの環境を見ずに見分けるのは難しいですが、同じ問題ではないと思います。 リリース間で二等分して、これがどこで変更されたかを正確に確認し、新しい問題を開くことをお勧めします。

私はこのためのPRに取り組んでいます。

私はこれがデフォルト設定に対して後退したと思います。 まだリリースされていないpip10のアップデートの波に巻き込まれた可能性がありますが、 @ JacobHennerがまだ追加していない場合は、それほど問題なくこれを取得できると思います。

公式のPyPiのキャッシングプロキシとしてdevpiを使用することについて話していると思います。 pip自体の場合、すべてのリクエストにローカルdevpiサーバーを使用するには、pipの/etc/pip.confと/usr/lib64/python3.6/disutils/distutils.cfgを変更する必要があります。

ただし、pipenvはこれらのシステム全体の設定を無視しているように見えるため、devpiサーバーを参照するようにPipfileの[[source]]構成設定を変更する必要があります。 ただし、Pipfileを外部に公開する場合、外部の貢献者は、実際に独自の環境を構築するために、 [[source]]の設定を削除する必要があります。

pipenvは/etc/pip.confと/usr/lib.../distutils.cfgのグローバル設定を尊重する必要があると思います

@ polski-g

公式のPyPiのキャッシングプロキシとしてdevpiを使用することについて話していると思います

Nexusリポジトリですが、ええ、同じ考えです。

ただし、pipenvはこれらのシステム全体の設定を無視しているようです

@techalchemyが述べたように、pipenv（11.6.0）はpip.conf （homedirも）を尊重していたと思いますが、最新バージョンはそうではありません-具体的には、どこかにハードコードされたpypi.org URLがあります（依存関係解決、IIRC）オーバーライドすることはできません。

pipenvは、/ etc /pip.confおよび/usr/lib.../distutils.cfgのグローバル設定を尊重する必要があると思います。

同意しました-個人的には、ユースケースでdistutils.cfgを変更する必要はありませんでした。

IIRCには、pip.confを尊重しないという解決策がありましたが、それを見つけるには、課題追跡システムを深く掘り下げる必要があります。 いずれにせよ、船は出航しており、PyPIミラーリングがほぼ完了しているため、近い将来、これが変更される可能性はほとんどありません。

この機能は次のリリースで出荷されると確信しています（運が良ければ翌日か2日で出荷されます）

また、これについてはよくわかりませんが、ここで構成パーサーを作成して構成のデフォルトを取得した後、 .load()を呼び出す必要がある可能性があります

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

@uranusjrは、ミラーリング構成が機能する限り（つまり、前述のハードコードされたpypi.org URLを使用しない限り）、pipenvが独自の構成を持ち、pipを無視しても問題はありません。

@brettdh私のブランチをチェックアウトして、それがあなたのブランチに適合していることを確認できますか？
ご使用の環境でのユースケース？

>>

@JacobHennerうん、ありがとう。 --pypi-mirrorオプション（ pipenv install 、 pipenv lock ）を使用した最初のテストは、正常に機能しているように見えます。 私はPRに小さな提案を残しました。

ただし、pypi.orgへのハードコードされたURLがまだpipenvソース全体に散在しているように見えるのではないかと少し心配しています。 [[source]]エントリからどれが正しくオーバーライドされているかわかりません。また、上記の問題の原因となったワークフローを正確に思い出せません。 したがって、修正されているかどうかを判断するのは困難です。 😬

ええ、このリリースに続いて、私は主要なコードのクリーンアップを計画しています。 CLIは、CLIに移動し、そこで例外をバブリングし、そこですべての出口を処理し、重複したコードを重複排除するなど、多くの作業が必要になります。ボランティアをしたい場合は、助けていただければ幸いです。

最近のバージョンをプルしただけで、ソースにpypi.orgがハードコーディングされています。 環境変数またはpypi-mirrorを取得し、それを[[source]]のデフォルトとして設定することが目標ですか？

編集：

コードを掘り下げただけです。

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",
    }

PIPENV_TEST_INDEXを環境変数PIPENV_PYPI_MIRRORに変更した場合は、良いスタートになると思います。

ここで説明するソリューションは、長い間実装されてきました。 引用したスニペットはデフォルトです。つまり、Pipfileの作成時にソースを指定しない場合に使用されます。

いいえ、Pipfileでソースを変更しないでください。 この変更の目標
ユーザーがミラーを使用してPyPIURLをオーバーライドできるようにすることでした。
Pipfile。

@JacobHennerミラー処理コードは、ソースリストを後処理し、 pypi.org URLを指定されたミラーへの参照に置き換えます。

これにより、 Pipfileに明示的なpypi.orgエントリがある場合でも、ミラーオーバーライドが機能します。 pipenvは、同じロジックに依存して、独自のデフォルトソースもオーバーライドします。

現在、その後処理が正しく適用されていない場合は、機能要求ではなく、すでに実装されている機能に対する新しいバグレポートです。

最後のコメントは@kylecribbsを対象としたものだと思いますか？

@JacobHennerああ、ごめんなさい-私はあなたのコメントを、その結果が実際に何であるかを明らかにすることを目的としたカイルへの応答としてではなく、この変更が当初の目標を達成しなかったと言ったと誤解しました。