/cc @uranusjr @ncoghlan @altendky @njsmith

Estoy convencido de que esto es algo que sucede comúnmente (FW corporativo / proxy de almacenamiento en caché). Siento que necesitamos una configuración de anulación para especificar un espejo para usar en lugar de pypi si lo encontramos en el archivo pip, como PIPENV_PYPI_MIRROR o PIPENV_PYPI_CACHING_PROXY o algo así para especificar que debe intentarse primero, dividido en sources delante de pypi básicamente.

¿Parece que logra el objetivo? Si es así, podemos etiquetar al genio de la implementación para que nos diga por qué esto es bueno o malo (@ncoghlan)

Comenzaré con una nota de precaución: hasta que PyPI haya implementado un mecanismo de firma de paquetes similar a PEP 458 para proporcionar una forma independiente de TLS por pip para garantizar que los paquetes que nominalmente se originan en PyPI realmente coincidan con lo que PyPI publicó. , entonces ofrecer la capacidad de redirigir el tráfico de forma transparente a un servidor diferente es realmente preocupante desde una perspectiva de seguridad.

Desafortunadamente, ese vector de ataque en particular ya está abierto a través de pip.conf , por lo que ofrecer algo comparable al nivel pipenv no hará que nada sea peor de lo que ya es.

Más allá de eso, creo que un mecanismo de reescritura de URL de repositorio de propósito general podría ser más fácil de documentar y explicar que algo específico de PyPI, al menos en la capa de capacidad básica. Algo como:

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

(El único bit específico de PyPI sería usar "predeterminado" para referirse a la fuente de descarga predeterminada de pip, como se especifica en pip.conf ).

Sin embargo, deletrear todo el mapa de anulación de la URL de origen cada vez sería difícil de usar en la práctica, por lo que un par de opciones para el azúcar CLI podrían verse como:

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

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

Si exponer o no la capa --override-source-url inmediatamente es una cuestión diferente: podría tener más sentido implementar primero la opción --pypi-mirror más simple, y simplemente mantener la posibilidad de --override-source-url y --override-source-urls como posibles opciones futuras en mente al hacerlo.

Un mapeo general {given URL: override URL} también fue lo primero que pensé, pero después de considerarlo más a fondo, hay algunos argumentos para PyPI de carcasa especial:

• PyPI es bastante único al tener una URL pública conocida y muchos espejos

• PyPI en realidad tiene varias URL (por ejemplo, probablemente tengamos Pipfiles dando vueltas por un tiempo con https://pypi.python.org/simple y https://pypi.org/simple , y tal vez también https://pypi.python.org/simple/ y https://pypi.org/simple/ con la barra inclinada al final?), y sería bueno si pudiéramos resolver esto una vez en lugar de obligar a cada usuario a resolverlo por sí mismos

@njsmith Vea la sugerencia de azúcar --pypi-mirror <URL> en la última parte de mi publicación: si la implementación inicial se centró únicamente en eso, entonces la capacidad general de reescritura de URL podría comenzar como un detalle de implementación interna (impulsado por el hecho de que " PyPI" tiene varias URL que finalmente se resuelven en el mismo lugar), y luego se considerará para su exposición como una función por derecho propio más adelante (después de que se haya confirmado que funciona como se desea para el uso principal --pypi-mirror caso).

Ah, cierto, me lo perdí :-)

¿Existe una regla general que asocie los argumentos de la línea de comandos a algún tipo de configuración más persistente? Me imagino que la mayoría de los usuarios de esto querrían configurarlo una vez y luego olvidarlo.

@ncoghlan escribió:

Comenzaré con una nota de precaución: hasta que PyPI haya implementado un mecanismo de firma de paquetes similar a PEP 458 para proporcionar una forma independiente de TLS para que pip garantice que los paquetes que nominalmente se originan en PyPI realmente coincidan con lo que PyPI publicó, entonces ofrece la capacidad redirigir el tráfico de forma transparente a un servidor diferente es realmente preocupante desde una perspectiva de seguridad.

Si estoy leyendo mi Pipfile.lock correctamente, no hay una relación almacenada entre un paquete y la fuente desde la que se instaló. Dado que el conjunto de características existente permite especificar múltiples fuentes, ¿no está creando un problema similar? Un sync podría terminar obteniendo un paquete de una fuente diferente a la que estaba acostumbrado al crear el archivo de bloqueo.

Pipfile.lock almacena una lista de hashes de artefactos aceptables para cada dependencia anclada, por lo que una vez que haya realizado un bloqueo, es difícil reemplazar los paquetes de manera subrepticia. En el momento de la generación del bloqueo, optar explícitamente por una fuente en Pipfile es decir "Confío en que esta fuente no se meta conmigo y usaré TLS para verificar que realmente estoy hablando con este punto de origen". (Creo que hay un problema en algún lugar al discutir la posibilidad de vincular paquetes particulares a repositorios de fuentes particulares, aunque puede estar en pip o en uno de los otros repositorios de PyPA, en lugar de aquí)

Cambiar la URL de índice predeterminada (o agregar una URL de índice adicional) en pip.conf , o usar la función de anulación propuesta aquí a través de un archivo de configuración o un mecanismo basado en un perfil de shell es diferente: eso es decir "Yo, o algún proceso arbitrario yo se ejecutó en algún momento con acceso de escritura a mi directorio de inicio (como un archivo setup.py de sdist), decidí configurar mi configuración para confiar en esta fuente de paquetes". E incluso un esquema de firma como PEP 458 no es una defensa completa contra ese tipo de travesuras si las claves públicas utilizadas para la verificación se almacenan en algún lugar dentro de su directorio de inicio en lugar de en un directorio que requiere privilegios elevados para modificar.

Hay buenas razones por las que las organizaciones con estrictos requisitos de seguridad ejecutan compilaciones en servidores bloqueados con solo acceso limitado a Internet en general, o monitorean este tipo de problemas a nivel de red :)

Tenga en cuenta también que si usa varios índices y un paquete proviene del índice no principal, se indicará en el archivo de bloqueo.

Las preocupaciones de pep 458 eran esencialmente lo que tenía en mente, ya que las cosas que son URL diferentes pero que en realidad apuntan a pypi son diferentes que si simplemente copiara pypi localmente y afirmara que era lo mismo.

Yo, o algún proceso arbitrario que ejecuté en algún momento con acceso de escritura a mi directorio de inicio (como un archivo setup.py de sdist), decidimos configurar mi configuración para confiar en esta fuente de paquetes

Si este es su modelo de amenaza, entonces no veo cómo algo que pipenv pueda hacer lo afectará mucho. Alguien que pueda modificar la configuración de su directorio de inicio también puede hacer cosas como insertar un nuevo directorio en $PATH e insertar allí un pipenv falso que haga lo que quiera.

@njsmith, este también es el modelo de amenaza de pip, porque la instalación del paquete requiere que se permita la ejecución de código arbitrario desde los archivos sdist setup.py . De hecho, ese código podría sobrescribir cosas en su directorio de inicio, como su configuración, o agregar cosas a su ruta, o cualquier cantidad de cosas. Es por eso que privilegiar explícitamente pypi (un índice conocido y confiable) y requerir la verificación de hash es un buen paso hacia la seguridad. Permite el control centralizado y la eliminación de amenazas de seguridad conocidas e identifica la verificación de los paquetes que está descargando de forma distribuida. ¿Qué decía el archivo de bloqueo que descargaste sobre el hash que deberías obtener? ¿No coincide con lo que obtienes del índice? Para que este modo de operación falle, debe tener fallas en más de una máquina local, índice y capa de red porque está hablando de tener múltiples paquetes dañados en su pila de aplicaciones trabajando en conjunto verificando hashes contra un índice confiable , y en muchos casos los propios hashes provenían de otra fuente no involucrada. Entonces, ahora debe tener, como mínimo, todas las comprobaciones de hash tanto en pip como en pipenv manipuladas de alguna manera de modo que genere hashes que sean idénticos a los que espera, pero ¿instala otras cosas maliciosas?

Supongo que lo que estoy diciendo es que si su máquina local está comprometida, pip o pipenv no van a hacer nada para salvarlo. Pero podemos asegurarnos de que el paquete que está descargando es el que estaba buscando, desde el lugar donde se suponía que debía buscarlo, lo que puede proporcionar un elemento en la cadena de seguridad.

@ncoghlan @njsmith ¿cómo influye todo esto en el movimiento para rechazar sudo pip install... y la sensación general que creo que todos tenemos de que si vas a usar pip, probablemente no deberías usar también tu administrador de paquetes del sistema para instalar cosas de python en términos generales. Esta no es realmente una pregunta de pipenv tal vez, pero es donde está la discusión en este momento y esto podría guiar los próximos pasos...

@techalchemy ¿No veo ninguna conexión con este tema? Creo que la conclusión de todo lo anterior es que permitir que los usuarios anulen qué espejo usa pipenv para PyPI no presenta ninguna amenaza adicional, y hacer sudo pipenv ni siquiera tiene sentido en primer lugar, ¿verdad?

@njsmith no, no creo que nadie deba usar sudo pipenv , como mencioné, no se trata realmente del tema, pero dado que recorrimos un poco el camino del modelo de amenaza, pensé que valía la pena explorarlo. Específicamente:

E incluso un esquema de firma como PEP 458 no es una defensa completa contra ese tipo de travesuras si las claves públicas utilizadas para la verificación se almacenan en algún lugar dentro de su directorio de inicio en lugar de en un directorio que requiere privilegios elevados para modificar.
Hay buenas razones por las que las organizaciones con estrictos requisitos de seguridad ejecutan compilaciones en servidores bloqueados con solo acceso limitado a Internet en general, o monitorean este tipo de problemas a nivel de red :)

Si una defensa, al menos en cierta medida, se basa en que las claves se almacenen en una ubicación privilegiada, pero desaconsejamos el uso de instalaciones de python privilegiadas, creo que posiblemente valga la pena discutirlo. Puede ser que esté equivocado. Pero definitivamente parece relacionado con el comentario de @ncoghlan (pero no sudo pipenv , eso nunca debería ser una cosa)

Sí, probablemente pareció que salió de la nada, solo un pensamiento al azar. Esperemos que el contexto adicional lo aclare un poco.

Voto por mantener este tema sobre el tema de ayudar a las personas que necesitan usar espejos PyPI, en lugar de entrar en una discusión especulativa sobre cómo podríamos implementar TUF. (De todos modos, no creo que haya mucho que podamos o debamos hacer para tratar de defendernos de un atacante que tiene acceso de escritura arbitrario al directorio de inicio del usuario).

Bien, definamos el comportamiento que esperaríamos o preferiríamos. Mi entendimiento de trabajo actual es que:

• Si se pasa --pypi-mirror o se establece PIPENV_PYPI_MIRROR , deberíamos preferir que
• ¿Deberíamos preferirlo a PyPI solamente? ¿Cómo evaluamos si una URL de índice determinada es 'PyPI'? No podemos consultarla, por lo que tendríamos que mantener una lista.
• ¿Debería la lista contener todas las permutaciones posibles, o deberíamos contentarnos con usar las dos URL que usamos en el pasado para generar Pipfiles como las cosas para las que deberíamos probar primero el espejo proporcionado?

Solo debe anular PyPI, no otras URL. Supongo que probablemente solo hay unas pocas URL de PyPI diferentes en uso, por lo que se pueden enumerar, y si nos perdemos una, alguien informará un error, se agregará y muy pronto las tendremos todas.

Me parece el enfoque correcto.

Lo que dijo @njsmith también coincide con mi perspectiva. Las 3 URL de repositorio que sugeriría reemplazar en un PR inicial serían:

• Ninguno configurado (es decir, cuando se confía en la configuración predeterminada de pip )
• https://pypi.python.org/simple
• https://pypi.org/simple

Es probable que la barra oblicua final se maneje mejor como un paso de normalización de URL, en lugar de enumerar las URL por separado.

Tenga en cuenta que las solicitudes de Pipfile tienen una barra inclinada al final (al momento de escribir) , por lo que probablemente necesitemos manejar esto de una forma u otra.

Bien, mi pensamiento fue:

• mantener una lista de URL sin barras inclinadas
• verifique las URL entrantes en busca de una barra diagonal final y elimínela si la encuentra ( str.rstrip probablemente sería lo suficientemente bueno para la tarea, aunque eliminaría una cantidad arbitraria de barras diagonales finales, o de lo contrario podríamos ser más estrictos al respecto, y eliminar como máximo una barra inclinada final)

Impresionante. Creo que esto es suficiente para trabajar y lo suficientemente simple para construir. ¡Gracias a todos!

La función de espejo Hope podría agregarse pronto ~

También me encuentro con este problema. La situación es:

• Tener un servidor PyPI interno con algunos paquetes privados.
• Tenga varias aplicaciones de Python que usen Pipenv para administrar sus dependencias.
• Algunas de las dependencias residen en el servidor PyPI interno y otras en el PyPI de la comunidad. El interno redirige a la comunidad PyPI para cualquier paquete no encontrado.

Mi estrategia de implementación ya configura un pip.conf en todo el sistema que se refiere al servidor PyPI interno. Sorprendentemente, descubrí que Pipenv ignora esta configuración.

Me doy cuenta de que si tuviera que mover/renombrar el PyPI interno, entonces varias aplicaciones con Pipfiles tendrían que actualizarse y sus archivos Pipfile.lock regenerarse. Una opción de espejo proporcionaría la funcionalidad deseada. También funcionaría y se sentiría menos redundante si Pipenv pudiera simplemente leer la configuración del sistema para Pip.

PRs bienvenido en este por cierto

Hola. Tengo la misma necesidad, pero dividiría esta función de anulación en otro ticket.

Aquí está mi propuesta de comportamiento esperado:

• se puede definir un archivo de configuración para establecer cada valor definido en la sección [[fuente]] del Pipfile.
• podría ser un archivo toml con solo la sección [[fuente]] del Pipfile
• La ubicación de este archivo está fuertemente inspirada en las reglas definidas para pip.conf (por ejemplo: /etc/pipenrc.toml, ~/.pipenvrc.toml
• Las variables de entorno también se pueden definir para anular estos valores (recordatorio: necesitamos todos los valores de [[fuente]]). por definir
• el comportamiento actual de pipenv es ahora:
  
  
  
  • al crear un Pipfile, toma los valores del archivo de configuración/variable de entorno
  
  
  • si no se define ningún archivo de configuración o variable de entorno, se aplica el comportamiento actual de pipenv
  
  
  • pipenv continúa generando siempre la sección [[fuente]] del Pipfile
  
  
  • si existe una sección [[fuente]] del Pipfile, pipenv no intenta anular nada con los valores del archivo de configuración.
  
  

Y en un segundo ticket, se pueden implementar las opciones de anulación. Tiene sentido, por ejemplo, dentro de un CI o algo así.

Como nota al margen: ahora usamos mucho pipenv en producción, pero necesito recordarles a todos con demasiada frecuencia que necesitan cambiar su Pipfile manualmente cuando comienzan un nuevo proyecto para acceder a nuestro repositorio Arrifactory Pypi (para información, Nexus también hace un Pypi caché de forma gratuita y funciona muy bien!). Tenemos un cortafuegos muy limitado y es una muy buena práctica dentro de una empresa almacenar en caché las dependencias externas, de modo que puedan respaldarse y verificarse en busca de vulnerabilidades, por ejemplo.
Si una característica simple similar al archivo de configuración general o de usuario (como ya lo hacemos para pip o npm), para que lo implementemos en todas nuestras estaciones de trabajo para que nuestros desarrolladores cometan menos errores, eso sería perfecto para mí)

Tal vez me perdí algo, pero esto parece una regresión. Hemos estado en 11.6.0 por un tiempo, y pipenv felizmente delegó la configuración en nuestro pip.conf, que apunta a un espejo pypi interno.

¿Alguna idea de cuándo se rompió esto? Hace que pipenv sea completamente inutilizable en nuestro contexto. Tengo problemas para ver esto como una "característica faltante" cuando aparentemente funcionó bien durante mucho tiempo.

Para ser claros: después de actualizar a 2018.05.18, incluso con el espejo especificado en nuestro Pipfile[.lock], pipenv intenta instalar nuevos paquetes desde pypi.org.

Quizás lo que estoy viendo es un tema aparte de este...

@brettdh Es difícil saberlo sin ver su entorno, pero creo que no es el mismo problema. Le sugiero que haga una bisección entre los lanzamientos para ver exactamente dónde cambió esto y abra un nuevo número para ello.

Estoy trabajando en las relaciones públicas para esto.

Creo que esto fue retrocedido con respecto a la configuración predeterminada. Es posible que se haya visto atrapado en una ola de actualizaciones para pip 10 que aún no se han lanzado, pero creo que podemos retomar esto sin demasiada dificultad si @JacobHenner aún no lo está agregando.

Supongo que está hablando de usar devpi como proxy de almacenamiento en caché para PyPi oficial. Para pip en sí, necesitaría modificar /etc/pip.conf y /usr/lib64/python3.6/disutils/distutils.cfg para que pip use su servidor devpi local para todas las solicitudes.

Sin embargo, parece que pipenv ignora esta configuración de todo el sistema, por lo que se ve obligado a modificar la configuración de configuración [[source]] en Pipfile para hacer referencia a su servidor devpi. Pero luego, si publica su Pipfile externamente, los colaboradores externos tienen que eliminar su configuración de [[source]] para construir su propio entorno.

Creo que pipenv debería respetar la configuración global de /etc/pip.conf y /usr/lib.../distutils.cfg

@polski-g

Supongo que está hablando de usar devpi como proxy de almacenamiento en caché para PyPi oficial

Nexus Repository, pero sí, la misma idea.

Sin embargo, parece que pipenv ignora estas configuraciones de todo el sistema

Como mencionó @techalchemy , creo que pipenv (11.6.0) solía respetar pip.conf (homedir también), pero la última versión no lo hace; específicamente, hay una URL de pypi.org codificada en alguna parte (dependencia resolución, IIRC) que no se puede anular.

Creo que pipenv debería respetar la configuración global de /etc/pip.conf y /usr/lib.../distutils.cfg

De acuerdo, aunque personalmente no he tenido que modificar distutils.cfg en mi caso de uso.

IIRC hubo una resolución para no respetar pip.conf, pero deberá profundizar en el rastreador de problemas para encontrarlo. En cualquier caso, el barco ha zarpado, y con la duplicación de PyPI casi terminada, es poco probable que esto cambie en un futuro próximo.

Estoy bastante seguro de que esta función se incluirá en la próxima versión (que se enviará en uno o dos días con suerte)

Tampoco estoy seguro de esto, pero es posible que necesitemos llamar a .load() después de crear el analizador de configuración aquí para obtener los valores predeterminados de configuración

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

@uranusjr siempre que la configuración de duplicación funcione (es decir, no use la URL codificada de pypi.org que mencioné), no veo ningún problema con pipenv que tenga su propia configuración para esto e ignore las de pip.

@brettdh ¿Podría verificar mi sucursal y confirmar que cumple con sus
caso de uso en su entorno?

>

@JacobHenner sí, gracias. Mi prueba inicial con la opción --pypi-mirror ( pipenv install , pipenv lock ) parece que funciona bien. Dejé una pequeña sugerencia sobre el PR.

Sin embargo, me preocupa un poco que las URL codificadas de pypi.org aún aparezcan dispersas en las fuentes de pipenv. No puedo estar seguro de cuáles se anulan correctamente de las entradas [[source]] , y no puedo recordar exactamente qué flujo de trabajo causó mi problema anterior. Así que es difícil saber si está arreglado. 😬

Sí, después de este lanzamiento, estoy planeando una limpieza importante del código. Las cosas de CLI se mueven a CLI, burbujean excepciones allí y manejan todas las salidas allí, deduplican código duplicado, etc. Va a ser mucho trabajo y se agradecerá la ayuda si alguien quiere ser voluntario: p

Acabo de sacar la versión reciente y todavía está codificando pypi.org en las fuentes. ¿El objetivo es tomar la variable ambiental o el espejo pypi y ponerlo como predeterminado para [[fuente]]?

editar:

Acabo de buscar en el código... Parece que tienes

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

Creo que si cambiaste If PIPENV_TEST_INDEX a la variable ambiental PIPENV_PYPI_MIRROR, sería un buen comienzo.

La solución discutida aquí se ha implementado durante mucho tiempo. El fragmento que citó es predeterminado , es decir, se usa si no proporciona una fuente al crear el Pipfile.

No, la fuente no debe cambiar en el Pipfile. El objetivo de este cambio
era permitir a los usuarios anular las URL de PyPI con un espejo, _sin_ cambiar
el archivo Pip.

@JacobHenner El código de manejo del espejo procesa la lista de origen y reemplaza las URL pypi.org con referencias al espejo especificado.

Eso es lo que permite que la anulación del espejo funcione incluso si hay una entrada pypi.org explícita en el Pipfile . pipenv luego se basa en esa misma lógica para anular también su propia fuente predeterminada.

Si actualmente hay casos en los que ese posprocesamiento no se aplica correctamente, se trata de un nuevo informe de error en relación con la función ya implementada, en lugar de una solicitud de función.

Creo que el último comentario estaba destinado a @kylecribbs.

@JacobHenner Ah, lo siento: malinterpreté su comentario diciendo que este cambio no había logrado su objetivo original, en lugar de ser una respuesta a Kyle que tenía como objetivo aclarar cuál era realmente ese resultado.