Назад | Перейти на главную страницу

Проблема с пакетом git opencsw в Solaris 10 с хостингом bitbucket git

Кто-нибудь пробовал использовать git из пакета opencsw для работы с сервисом хостинга исходных кодов bitbucket (под solaris10)?

Я попытался использовать git, как объясняется в документации по битбакету, и - под Debian GNU / Linux он работал безупречно, как описано, но - под Solaris 10 я получил сообщение Authentication Failed.

Я даже попытался запустить ферму, чтобы увидеть что-нибудь подозрительное, но не смог найти дымящийся пистолет под солярисом, почему это не удалось. ldd git-binary также не показал ничего подозрительного (за исключением библиотеки libcrypt, которая может быть подозрительной, если подумать об ограничениях на экспорт. Они отправили несовместимую версию? НО, поскольку пароль вводится в https: connection, я подозреваю, что это всего лишь вопрос криптографии веб-уровня и должен быть универсальным в наши дни.)

Сейчас у меня возникает соблазн скомпилировать git suite под solaris 10, но я нашел людей, которые, похоже, используют git с bitbucket под solaris 10, и мне интересно, что может быть не так.

ПРИМЕЧАНИЕ. В первоначальном посте я не упомянул четко, что для GIT отказал транспорт HTTPS.

То есть, когда я следил за учебником по битбакету,

git clone https: .... не удалось. (Здесь используется HTTPS-соединение.)

Но после этой неудачи я попытался использовать SSH.

git clone git: .... выполнено.

(Это использует базовое соединение SSH.)

Это означает, что какой-либо механизм, используемый командой git для отправки пароля по протоколу HTTPS, завершился неудачно.

Учитывая, что у нас может быть много проблем с попыткой обойти брандмауэр для SSH, в то время как доступ через HTTP или HTTPS почти повсеместен, я бы хотел, чтобы команда «git clone https: ...» была успешной.

solaris git

Я откопал несколько кандидатов дымящегося пистолета.

Я думаю, что последняя версия OpenSSL должна быть доступна.

[] Первоначальный лид: GIT_SSL_NO_VERIFY

Следующее касается использования git под XP, но оказывается, что это тоже несколько косвенно связано с моей проблемой. По крайней мере, использование GIT_SSL_NO_VERIFY является для меня новостью, а обходной путь, использующий GIT_SSL_NO_VERIFY, для меня не сработал, поэтому я мог вернуться к другим возможным реальным причинам.

https://stackoverflow.com/questions/3777075/https-github-access

Я последовал первому предложению из указанного выше URL (использование GIT_SSL_NO_VERIFY). Но это не решило проблему. Итак, мой следующий след был о том, может быть, версия библиотеки curl устарела?

Цитата из сообщения выше: ---- начать цитату

Проблема в том, что в вашей системе не установлены сертификаты центра сертификации. И эти сертификаты не могут быть установлены с помощью setup.exe cygwin.

Есть два решения: 1. Игнорировать проверку сертификата ssl:

$ env GIT_SSL_NO_VERIFY=true git clone https://github...

Собственно установить корневые сертификаты. Ребята Curl извлекли для вас сертификаты из Mozilla:

http://curl.haxx.se/docs/caextract.html

Файл cacert.pem - это то, что вы ищете. Этот файл содержит> 250 сертификатов CA (не знаю, как доверять этому количеству ppl). Вам необходимо загрузить этот файл, разделить его на отдельные сертификаты, поместить их в / usr / ssl / certs (ваш CApath) и проиндексировать их. ************************* 8 в Solaris: CApath: / opt / csw / ssl / certs

Вот как это сделать: С помощью cygwin setup.exe установите пакеты curl и openssl. Выполните:

$ cd /usr/ssl/certs
$  curl http://curl.haxx.se/ca/cacert.pem | awk 'split_after==1{n++;split_after=0} /-----END CERTIFICATE-----/ {split_after=1} {print > "cert" n ".pem"}'
$ c_rehash

---- конец цитаты

Я попробовал GIT_SSL_NO_VERIFY = true, но все еще без кубиков. Так что сертификаты, вероятно, не являются прямой причиной проблем.

После поиска подсказок я нашел

GIT_CURL_VERBOSE=1
export GIT_CURL_VERBOSE

дает много результатов, чтобы следить за тем, что происходит. Я прилагаю подробный вывод для сравнения под solaris и linux.

[] Доступность CERT оказалась несущественной для моей проблемы.

git, использующий транспорт https, работал под Linux. Дистрибутив, который я использую (сейчас Debian), устанавливает некоторые сертификаты открытых ключей из центров сертификации, что помогает git определять действительность сертификата bitbuckt и т. д.

В Solaris10 репозиторий opencsw, похоже, уже установил некоторые сертификаты в / opt / csw / ssl / certs.

Так что наличие сертификатов не было проблемой (или нет?). И следующий журнал, созданный GIT_CURL_VERBOSE, похоже, предполагает (хотя и в некоторой спартанской манере под Solaris), что сертификат проверен.

[] библиотеки и команды смешаны из sfw и opencsw

Тогда почему версия git для Solaris не работает по протоколу https?

Кажется, что git использует libcurl и друзей. Возможно, libcurl из пакета opencsw не скомпилирован с опцией "with-ssl" (?)

Команда curl-config, если она доступна, выводит версию, а команда curl --version показывает встроенный протокол и т. д.

Проверяя каталог с номерами версий библиотек, перечисляя библиотеки, я заметил серьезную путаницу с Solaris 10. Есть две версии ssl и libcurl. Один из opencsw, а другой из несколько более старого дистрибутива sfw (sun freeware), и я боюсь, что несколько лет назад sfw был предпочтительным выбором. И, в довершение всего, сама команда curl взята из sfw (по крайней мере, в моей версии Solaris x86 (64 бита)!)

Вы можете видеть, что комбинация по-королевски перемешана на моем изображении Solarix 10.

Связанные с SFW:

zephyr@zephyrus:~/repos$ ls /usr/sfw/lib/*ssl*
/usr/sfw/lib/libssl.so@              /usr/sfw/lib/llib-lssl
/usr/sfw/lib/libssl.so.0.9.7*        /usr/sfw/lib/llib-lssl.ln
/usr/sfw/lib/libssl_extra.so.0.9.7*
zephyr@zephyrus:~/repos$
ls /opt/sfw/bin/*curl*
/opt/sfw/bin/curl*         /opt/sfw/bin/curl-config*
zephyr@zephyrus:~/repos$ which curl
/opt/sfw/bin/curl

Связанные с CSW:

ls -l /opt/csw/lib/*curl*
lrwxrwxrwx   1 root     root          16 Mar 18 18:00 /opt/csw/lib/libcurl.so.4 -> libcurl.so.4.2.0*
-rwxr-xr-x   1 root     bin       689040 Feb 23 19:38 /opt/csw/lib/libcurl.so.4.2.0*
zephyr@zephyrus:~/repos$ ls -l /opt/csw/lib/*ssl*
lrwxrwxrwx   1 root     root          29 Mar 18 17:57 /opt/csw/lib/libgnutls-openssl.so.26 -> libgnutls-openssl.so.26.16.13*
-rwxr-xr-x   1 root     bin        70432 Jan 18  2011 /opt/csw/lib/libgnutls-openssl.so.26.16.13*
-rw-r--r--   1 root     bin       527064 Jan 24 06:08 /opt/csw/lib/libssl.a
lrwxrwxrwx   1 root     root          15 Mar 27 22:04 /opt/csw/lib/libssl.so -> libssl.so.0.9.8*
-r-xr-xr-x   1 root     bin       314056 Jan  3  2008 /opt/csw/lib/libssl.so.0.9.7*
-r-xr-xr-x   1 root     bin       388928 Jan 24 06:08 /opt/csw/lib/libssl.so.0.9.8*
zephyr@zephyrus:~/repos$

Хорошо, какие библиотеки использует sfw-версия curl? Использует CSW-раздачу, если есть! (Я поставил / opt / csw / lib в начале моего LD_LIBRARY_PATH. Думаю, поэтому именно поэтому.)

zephyr@zephyrus:~/repos$ ldd /opt/sfw/bin/curl
        libcurl.so.4 =>  /opt/csw/lib/libcurl.so.4
        libssl.so.0.9.7 =>       /opt/csw/lib/libssl.so.0.9.7
        libcrypto.so.0.9.7 =>    /opt/csw/lib/libcrypto.so.0.9.7
        libsocket.so.1 =>        /lib/libsocket.so.1
        libnsl.so.1 =>   /lib/libnsl.so.1
        libdl.so.1 =>    /lib/libdl.so.1
        libz.so.1 =>     /opt/csw/lib/libz.so.1
        libz.so.1 (SUNW_1.1) =>  (version not found)
        libc.so.1 =>     /lib/libc.so.1
        libidn.so.11 =>  /opt/csw/lib/libidn.so.11
        libssl.so.0.9.8 =>       /opt/csw/lib/libssl.so.0.9.8
        libcrypto.so.0.9.8 =>    /opt/csw/lib/libcrypto.so.0.9.8
        libmp.so.2 =>    /lib/libmp.so.2
        libmd.so.1 =>    /lib/libmd.so.1
        libscf.so.1 =>   /lib/libscf.so.1
        libintl.so.8 =>  /opt/csw/lib/libintl.so.8
        libiconv.so.2 =>         /opt/csw/lib/libiconv.so.2
        libdoor.so.1 =>  /lib/libdoor.so.1
        libuutil.so.1 =>         /lib/libuutil.so.1
        libgen.so.1 =>   /lib/libgen.so.1
        libm.so.2 =>     /lib/libm.so.2
zephyr@zephyrus:~/repos$

[] команда git-remote-https.

Копнув дальше, я заметил, что есть команда git-remote-https в каталоге / opt / csw / libexec / git-core. Похоже, это используется командой git clone https: .... (Я обнаружил это с помощью переменной среды GIT_TRACE = 1.)

zephyr@zephyrus:~/repos$ ldd /opt/csw/libexec/git-core/git-remote-https
        libpthread.so.1 =>       /lib/libpthread.so.1
        libintl.so.8 =>  /opt/csw/lib/libintl.so.8
        libz.so.1 =>     /opt/csw/lib/libz.so.1
        libiconv.so.2 =>         /opt/csw/lib/libiconv.so.2
        libsocket.so.1 =>        /lib/libsocket.so.1
        libnsl.so.1 =>   /lib/libnsl.so.1
        libresolv.so.2 =>        /lib/libresolv.so.2
        libcrypto.so.0.9.8 =>    /opt/csw/lib/libcrypto.so.0.9.8
        libcurl.so.4 =>  /opt/csw/lib/libcurl.so.4
        libexpat.so.1 =>         /opt/csw/lib/libexpat.so.1
        libc.so.1 =>     /lib/libc.so.1
        libmp.so.2 =>    /lib/libmp.so.2
        libmd.so.1 =>    /lib/libmd.so.1
        libscf.so.1 =>   /lib/libscf.so.1
        libdl.so.1 =>    /lib/libdl.so.1
        libidn.so.11 =>  /opt/csw/lib/libidn.so.11
        libssl.so.0.9.8 =>       /opt/csw/lib/libssl.so.0.9.8
        libdoor.so.1 =>  /lib/libdoor.so.1
        libuutil.so.1 =>         /lib/libuutil.so.1
        libgen.so.1 =>   /lib/libgen.so.1
        libm.so.2 =>     /lib/libm.so.2
zephyr@zephyrus:~/repos$

Поэтому он использует libcurl и libssl из / opt / csw / lib.

У этого openssl может быть проблема с пунктом 2, указанным выше. Ну что ж.

[] Сравнение версий: solaris 10 vs linux

В версии opencsw Solaris (где git clone https: ... не удалось)

curl-config --version
libcurl 7.16.4

curl --version
curl 7.16.4 (i386-pc-solaris2.10) libcurl/7.24.0 OpenSSL/0.9.7m zlib/1.2.5 libidn/1.24
Protocols: dict file ftp ftps gopher http https imap imaps pop3 pop3s rtsp smtp smtps telnet tftp
Features: IDN IPv6 Largefile NTLM SSL libz

На linux (где успех): как-то не смог найти curl-config

/usr/bin/curl --version
curl 7.24.0 (i486-pc-linux-gnu) libcurl/7.24.0 OpenSSL/1.0.0h zlib/1.2.6 libidn/1.24 libssh2/1.2.8 librtmp/2.3
Protocols: dict file ftp ftps gopher http https imap imaps ldap pop3 pop3s rtmp rtsp scp sftp smtp smtps telnet tftp 
Features: Debug TrackMemory GSS-Negotiate IDN IPv6 Largefile NTLM NTLM_WB SSL libz 
zephyrus@debian-vm:~/repos$

Обратите внимание, что OpenSSL составляет 1.0h в Linux, а в Solaris - 0.9.7 м (!). Это вполне может быть проблемой.

[] Простое выполнение curl: сбой работы libcurl?

Я проверил базовую работу libucurl, выполнив следующую команду как под solaris10 (сбой), так и под Debian GNU / Linux (успешно).

curl -v  https://myuserid@bitbucket.org/myuserid/bb101rep.git

Я заметил разницу сразу. Подробный вывод curl вначале под linux показал следующее, а на solaris - нет. Так что, возможно, рукопожатие sslv3 по какой-то причине не беспокоит.

(Из дампа linux)

* SSLv3, TLS handshake, Client hello (1):
* SSLv3, TLS handshake, Server hello (2):
* SSLv3, TLS handshake, CERT (11):
* SSLv3, TLS handshake, Server finished (14):
* SSLv3, TLS handshake, Client key exchange (16):
* SSLv3, TLS change cipher, Client hello (1):
* SSLv3, TLS handshake, Finished (20):
* SSLv3, TLS change cipher, Client hello (1):
* SSLv3, TLS handshake, Finished (20):

Может быть, следующие строки из вывода curl показывают какие-то отношения? Обратите внимание на следующие моменты.

Из журнала Solaris 10:

* SSL: couldn't set callback! (<--- ? point 1 ?)
* successfully set certificate verify locations:  
*   CAfile: none
  CApath: /opt/csw/ssl/certs
* WARNING: failed to configure server name indication (SNI) TLS
  extension (<===? point 2??)
* SSL connection using AES256-SHA

[] Может, дымящийся пистолет, наконец.

Что касается пункта 2 в предыдущем разделе, я нашел ссылку на ошибку в openssl:

http://curl.haxx.se/mail/lib-2009-09/0294.html

но это было «проблема была введена в 0.9.7f и была исправлена в 0.9.8k» и поэтому не должна быть проблемой в 0.9.7m, который использует opencsw curl.

Но кто знает, скрываются ли другие ошибки в openssl до 1.0.0. Например, следующая ошибка с OpenSSL 0.9.8g

http://rt.openssl.org/Ticket/Display.html?id=1629

также упоминается в

http://serverfault.com/questions/303090/stunnel-wont-work-with-sslv3-from-some-hosts

здесь может иметь значение.

По поводу пункта 1 я нашел следующий пост. Это также может способствовать возникновению проблемы. Кажется, что если curl ВСТРОЕН против sfw libssl, он терпит неудачу в некоторой степени (!).

RE: не удалось установить обратный вызов! (РЕШЕНО)

http://curl.haxx.se/mail/archive-2010-04/0093.html

Я подозреваю, что этот пост может иметь отношение к делу и указывает на виновника (он специфичен для Solaris 10!)

В любом случае, я опубликую свой результат в opencsw и попрошу собрать openssl 1.0.0h и перестроить библиотеку curl для него, а затем также git.

Я пришел к выводу, что если openssl на основе 1.0.0h станет доступным, а curl, libcurl и git перекомпилированы, то проблема с «git clone https: ...», которую я видел, может не возникнуть.

Справочный журнал

[] curl log: сбой в Solaris 10

curl -v  https://bitbucket.org/userid/bb101repo.git/info/refs?service=git-upload-pack

* About to connect() to bitbucket.org port 443 (#0)
*   Trying 207.223.240.182...
* connected
* Connected to bitbucket.org (207.223.240.182) port 443 (#0)
* SSL: couldn't set callback!
* successfully set certificate verify locations:
*   CAfile: none
  CApath: /opt/csw/ssl/certs
* WARNING: failed to configure server name indication (SNI) TLS extension
  ??? key exchange is missing here in comparison to linux dump ...???
* SSL connection using AES256-SHA
* Server certificate:
*        subject: 2.5.4.15=Private Organization; 1.3.6.1.4.1.311.60.2.1.3=US; 1.3.6.1.4.1.311.60.2.1.2=Delaware; serialNumber=3928449; streetAddress=375 Alabama St Ste 325; postalCode=94110; C=US; ST=CA; L=San Francisco; O=Atlassian, Inc.; CN=bitbucket.org
*        start date: 2012-01-03 00:00:00 GMT
*        expire date: 2014-03-12 12:00:00 GMT
*        subjectAltName: bitbucket.org matched
*        issuer: C=US; O=DigiCert Inc; OU=www.digicert.com; CN=DigiCert High Assurance EV CA-1
*        SSL certificate verify ok.
> GET /userid/bb101repo.git/info/refs?service=git-upload-pack HTTP/1.1
> User-Agent: curl/7.16.4 (i386-pc-solaris2.10) libcurl/7.24.0 OpenSSL/0.9.7m zlib/1.2.5 libidn/1.24
> Host: bitbucket.org
> Accept: */*
>
< HTTP/1.1 404 NOT FOUND
< Server: nginx/1.0.6
< Date: Fri, 30 Mar 2012 18:04:59 GMT
< Content-Type: text/html; charset=utf-8
< Transfer-Encoding: chunked
< Connection: close
< Vary: Cookie
<

        html payload omitted. ...

        ...
* Closing connection #0
zephyr@zephyrus:~/repos$

[] curl log: успех под LINUX

curl -v https://userid@bitbucket.org/userid/bb101repo.git
* About to connect() to bitbucket.org port 443 (#0)
*   Trying 207.223.240.182...
* connected
* Connected to bitbucket.org (207.223.240.182) port 443 (#0)
* successfully set certificate verify locations:
*   CAfile: none
  CApath: /etc/ssl/certs
* SSLv3, TLS handshake, Client hello (1):
* SSLv3, TLS handshake, Server hello (2):
* SSLv3, TLS handshake, CERT (11):
* SSLv3, TLS handshake, Server finished (14):
* SSLv3, TLS handshake, Client key exchange (16):
* SSLv3, TLS change cipher, Client hello (1):
* SSLv3, TLS handshake, Finished (20):
* SSLv3, TLS change cipher, Client hello (1):
* SSLv3, TLS handshake, Finished (20):
* SSL connection using AES256-SHA
* Server certificate:
*    subject: businessCategory=Private Organization; 1.3.6.1.4.1.311.60.2.1.3=US; 1.3.6.1.4.1.311.60.2.1.2=Delaware; serialNumber=3928449; street=375 Alabama St Ste 325; postalCode=94110; C=US; ST=CA; L=San Francisco; O=Atlassian, Inc.; CN=bitbucket.org
*    start date: 2012-01-03 00:00:00 GMT
*    expire date: 2014-03-12 12:00:00 GMT
*    subjectAltName: bitbucket.org matched
*    issuer: C=US; O=DigiCert Inc; OU=www.digicert.com; CN=DigiCert High Assurance EV CA-1
*    SSL certificate verify ok.
* Server auth using Basic with user 'userid'
> GET /userid/bb101repo.git HTTP/1.1
> Authorization: Basic emVwaHlydXMwMGpwOg==
> User-Agent: curl/7.24.0 (i486-pc-linux-gnu) libcurl/7.24.0 OpenSSL/1.0.0h zlib/1.2.6 libidn/1.24 libssh2/1.2.8 librtmp/2.3
> Host: bitbucket.org
> Accept: */*
> 
* additional stuff not fine transfer.c:1037: 0 0
* HTTP 1.1 or later with persistent connection, pipelining supported
< HTTP/1.1 404 NOT FOUND
< Server: nginx/1.0.6
< Date: Fri, 30 Mar 2012 18:17:29 GMT
< Content-Type: text/html; charset=utf-8
< Transfer-Encoding: chunked
< Connection: close
< Vary: Cookie
< 

  ... payload omitted ...


* Closing connection #0
remote: Counting objects: 3, done.
remote: Compressing objects:   ...
...      
Unpacking objects: 100% (3/3), done.
zephyrus@debian-vm:~/repos$ exit
exit

Сценарий написан 03.03.2012 31.01.01 45.21.01