Pip всегда терпит неудачу ssl проверка

Пип всегда терпит неудачу ssl, даже когда я делаю pip install dedupe или pip install --trusted-host pypi.python.org dedupe

Выход всегда одинаковый независимо от того, что:

Сбор дедуплий

Повторная попытка (Retry (total = 4, connect = None, read = None, redirect = None, status = None)) после завершения соединения 'SSLError (SSLError (1,' [SSL: CERTIFICATE_VERIFY_FAILED] сертификат Не удалось выполнить проверку (_ssl.c: 777) '),)':/simple/dedupe/
Повторная...

пропуск

Не удалось найти версию, которая удовлетворяет требованию dedupe (из версий:) Не найдено соответствующего распределения для dedupe

Итак, я удалил anaconda и переустановил его. То же самое.

Как вы думаете, проблема в том, что мой файл _ssl.c(который я не знаю, где он) должен быть поврежден или что-то еще? Почему pip должен ссылаться на это, если я говорю об этом, чтобы обойти проверку ssl в любом случае?

Ответ 1

Это может быть связано с изменением доменов PyPI в 2018 году.
Убедитесь, что ваш брандмауэр/прокси-сервер разрешает доступ к/из:

  • pypi.org
  • files.pythonhosted.org

Таким образом, вы можете попробовать что-то вроде:

$ python -m pip install --trusted-host files.pythonhosted.org --trusted-host pypi.org --trusted-host pypi.python.org [--proxy...] [--user] <packagename>

Пожалуйста, смотрите $ pip help install для --user опции --user (опустите, если в virtualenv).
Опция --trusted-host самом деле не обходит SSL/TLS, но позволяет пометить хост как надежный, когда (и только когда) у него нет действительного (или какого-либо) HTTPS. Это не должно иметь большого значения для PiPY, потому что pypi.org (ранее pypi.python.org) действительно использует HTTPS, и перед ним есть CDN, который всегда обеспечивает требование рукопожатия TLSv1.2 независимо от параметров подключаемого клиента pip. Но если у вас были свои локальные зеркала pypi.org с доступом только по HTTP, тогда --trusted-host может быть --trusted-host. Да, и если вы находитесь за прокси-сервером, также обязательно укажите: --proxy [user:[email protected]]proxyserver:port
Некоторые корпоративные прокси-серверы могут даже пойти на замену сертификатов HTTPS-соединений на лету. И если ваши системные часы не синхронизированы, это также может нарушить процесс проверки SSL.

Если брандмауэр/прокси/часы не являются проблемой, то проверьте SSL-сертификаты, используемые в рукопожатии SSL в pip. На самом деле, вы можете просто получить текущий cacert.pem (пакет Mozilla CA из curl) и попробовать его, используя параметр pip --cert:

$ pip --cert ~/cacert.pem install --user <packagename>
где аргумент --cert - системный путь к альтернативному --cert CA в формате PEM. (относительно опции --user, пожалуйста, смотрите ниже).
Или можно создать пользовательскую конфигурацию ~/.pip/pip.conf и указать опцию на действительный системный сертификат (или ваш cacert.pem) в качестве обходного пути, например:
[Глобальный]
cert =/etc/pki/tls/external-roots/ca_bundle.pem
(или другой файл pem)

Можно даже вручную заменить оригинальный cacert.pem, найденный в pip, на ваш верный пакет CA (например, если ваш pip очень старый). Более ранние версии пипсов, как известно, имели запасной вариант между pip/_vendor/запросы/cacert.pem и системными хранилищами, такими как /etc/ssl/certs/ca-certificates.crt или /etc/pki/tls/certs/ca-bundle.crt в случае проблемы с сертификатом, но в последнем пипе это уже не так, так как кажется, что он полагается исключительно на pip/_vendor/certifi/cacert.pem

По сути, пакет pip использует requests использующие urllib3 который, помимо прочего, проверяет сертификаты SSL; и все они поставляются (продаются) в рамках pip вместе с пакетом certifi (также включенным, начиная с pip 9.0.2), который предоставляет текущий пакет CA (файл cacert.pem), необходимый для проверки TLS. Сам по себе запрос использует urllib3 и certifi для внутреннего использования, а до 9.0.2 pip использовал cacert.pem из запросов или системы. Все это означает, что собственно обновление pip может помочь исправить ошибку CERTIFICATE_VERIFY_FAILED, особенно если ОС и pip были развернуты давно:

  • ОП использовал анаконду, чтобы они могли попробовать:
    $ conda update pip - потому что могут возникнуть проблемы, если conda и pip используются вместе в одной среде. Если обновление версии pip недоступно, они могут попробовать:
    $ conda config --add channels conda-forge; conda update pip
    В качестве альтернативы можно использовать только conda для непосредственной установки/управления пакетами Python: это инструмент, полностью отделенный от pip, но обеспечивающий аналогичные функции с точки зрения управления пакетами и venv. Его пакеты приходят не из PyPI, а из собственных репозиториев Anaconda. Проблема в том, что если вы смешаете оба и запускаете conda после pip, первый может перезаписать и разорвать пакеты (и их зависимости), установленные через pip, и сделать все это непригодным для использования. Поэтому рекомендуется использовать только один или другой, или, если необходимо, использовать только pip после conda (и не conda после pip), и только в изолированных условиях conda.

  • На обычных установках Linux Python без conda:
    Если вы используете версию pip, поставляемую дистрибутивом ОС, то используйте обновления, предоставляемые поставщиком, для общесистемного обновления pip:
    $ sudo apt-get install python-pip или: $ sudo yum install python27-pip
    Некоторые обновления могут быть недоступны, поскольку дистрибутивы обычно отстают от PyPI. В этом случае можно обновить pip на уровне пользователя (прямо в директории $ HOME) или внутри virtualenv, например:
    $ python -m pip install --user --trusted-host files.pythonhosted.org --trusted-host pypi.org --trusted-host pypi.python.org --upgrade pip
    (опустить --user если в virtualenv)
    Переключатель --user обновит pip только для текущего пользователя (у вас дома ~/.local/lib/), а не для всей ОС, что является хорошей практикой во избежание вмешательства в системные пакеты python. Он включен по умолчанию в пипсах, распространяемых в последних версиях Ubuntu/Fedora. Знайте, как решить ImportError, если вы не используете эту опцию и случайно перезаписали системный пип на уровне ОС.
    В качестве альтернативы (также на уровне пользователя) вы можете попробовать:
    $ curl -LO https://bootstrap.pypa.io/get-pip.py && python get-pip.py --user
    PyPA сценарий содержит оболочку, которая извлекает .pem SSL сверток из pip._vendor.certifi.

В противном случае, если все еще нет, попробуйте запустить pip с -vvv чтобы добавить многословность к выходным данным и проверить, есть ли еще один SSLError вызванный версией протокола оповещения tlsv1.

Ответ 2

Вышеприведенная ошибка или такая, как она была вызвана тем, что виртуальная машина (ВМ) не синхронизирована по времени, моя гостевая виртуальная машина Ubuntu прошла несколько дней назад.

Я выполнил эту рекомендацию, чтобы виртуальная машина выбрала правильное сетевое время:

sudo timedatectl set-ntp on

Гостевая ОС Ubuntu получает сетевое время. (Возможно, вам придется указать сетевой источник времени... Я использовал эту статью: Digital Ocean - Как установить время в Ubuntu)

Проверьте правильность времени:

timedatectl

Перезапустите сбойную команду pip.