☰

Solaris 10 opencsw git 软件包与 bitbucket git 托管有关的问题

tag-icon • tag-icon solaris git
Solaris 10 opencsw git 软件包与 bitbucket git 托管有关的问题

是否有人尝试过使用 opencsw 包中的“git”来使用 bitbucket 源托管服务（在 solaris10 下）？

我尝试按照 bitbucket 文档的说明使用 git，在 Debian GNU/Linux 下，它按照描述完美地运行，但在 Solaris 10 下，我收到了身份验证失败消息。

我甚至尝试运行 truss 来查看是否有任何可疑之处，但在 solaris 下找不到任何导致失败的确凿证据。ldd git-binary 也没有显示任何可疑内容（除了 libcrypt 库，这可能是一个可疑的出口限制。他们是否发布了不兼容的版本？但是由于密码是在 https: 连接中输入的，我怀疑这只是一个网络级加密的问题，现在应该是通用的。）

我现在想在 solaris 10 下编译 git suite，但我发现有人似乎在 solaris 10 下使用 git 和 bitbucket，我想知道可能出了什么问题。

注意：在最初的帖子中，我没有清楚地提到 GIT 的 HTTPS 传输失败了。

也就是说，当我按照 bitbucket 教程操作时，

  • git clone https:.... 失败。 （这使用 HTTPS 连接。）

但那次失败之后，我尝试使用 SSH。

  • git clone git：....成功。

    （这使用底层 SSH 连接。）

这意味着 git 命令使用的任何机制通过 HTTPS 协议发送密码都失败了。

鉴于我们在尝试绕过 SSH 防火墙时可能会遇到很多问题，而通过 HTTP 或 HTTPS 访问几乎无处不在，我希望看到“git clone https：...”能够成功。

答案1

我挖掘出了一些确凿证据的候选人。

我认为需要提供最新的 OpenSSL。

[] 初始线索：GIT_SSL_NO_VERIFY

下面的内容是关于在 XP 下使用 git 的，但事实证明它也与我的问题有某种间接关系。至少 GIT_SSL_NO_VERIFY 的使用对我来说是个新鲜事，而使用 GIT_SSL_NO_VERIFY 的解决方法对我来说不起作用，因此我可以找到其他可能的真实原因。

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

我按照上述 URL 中的第一个建议操作（使用 GIT_SSL_NO_VERIFY）。但这并没有解决问题。所以我的下一个尝试是看看 curl 库版本是否过时了？

引用上面的帖子：---- 开始引用

问题是您的系统上没有安装任何证书颁发机构的证书。并且这些证书无法使用 cygwin 的 setup.exe 安装。

解决办法有两种：1.忽略ssl证书验证：

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

  1. 实际安装根证书。Curl 帮你从 mozilla 提取了证书：

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

cacert.pem 文件就是您要找的。此文件包含 > 250 个 CA 证书（不知道如何信任这么多人）。您需要下载此文件，将其拆分为单个证书，将它们放在 /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）安装了一些来自 CA 的公钥证书，这有助于 git 确定 bitbuckt 证书的有效性等。

在 solaris10 下，opencsw 存储库似乎已经在 /opt/csw/ssl/certs 下安装了一些证书。

因此，拥有证书似乎不是问题（或者说是问题？）。并且 GIT_CURL_VERBOSE 生成的以下日志似乎表明（尽管在 solaris 下有点简陋）证书已经过验证。

[] sfw 和 opencsw 混合的库和命令

那么为什么 solaris 版本的 git 使用 https 协议不会失败？

git 似乎使用了 libcurl 和相关库。也许 opencsw 包中的 libcurl 未使用“with-ssl”选项进行编译 (?)

如果可用，curl-config 命令将打印版本，curl --version 将显示内置协议等。

通过列出库来检查库版本号目录时，我注意到 solaris 10 上存在严重混乱。ssl 和 libcurl 有两个版本。一个来自 opencsw，另一个来自稍旧的 sfw（sun 免费软件）发行版，我担心 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-distribution！（我将 /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 命令。

进一步挖掘后，我注意到 /opt/csw/libexec/git-core 目录下有 git-remote-https 命令。这似乎是由 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$

因此它使用来自 /opt/csw/lib 的 libcurl 和 libssl。

此 openssl 可能存在上述第 2 点的问题。算了。

[] 版本比较：solaris 10 vs linux

在 Solaris opencsw 版本上（其中 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 在 Linux 下为 1.0h，而在 Solaris 上为 0.9.7m (!)。这很可能就是问题所在。

[] 简单的curl执行：libcurl操作失败？

我通过在 solaris10（失败）和 Debian GNU/Linux（成功）下运行以下命令检查了 libucurl 的基本操作。

curl -v  https://[email protected]/myuserid/bb101rep.git

我注意到的差异是立竿见影的。在 Linux 下，curl 的详细输出在开头附近显示了以下内容，而在 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 中的一个 bug 的引用：

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

但“该问题是在 0.9.7f 中引入的，并在 0.9.8k 中得到了修复”，因此在 opencsw curl 使用的 0.9.7m 中应该不是问题。

但谁知道 1.0.0 之前的 OpenSSL 中是否还隐藏着其他错误。例如，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 构建的，它以一种微妙的方式失败了（！）。

回复：无法设置回调！（已解决）

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

我怀疑上述帖子可能相关且指出了罪魁祸首（它是 solaris 10 特有的！）

无论如何，我都会将我的发现发布到 opencsw 并要求构建 openssl 1.0.0h 并根据它重建 curl 库，然后 git 也一样。

我的结论是，如果基于 1.0.0h 的 openssl 可用，并且重新编译 curl、libcurl 和 git，那么我看到的“git clone https：...”的问题可能就不会发生。

参考日志

[] curl 日志：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 日志：LINUX 下成功

curl -v https://[email protected]/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

脚本完成于 2012年03月31日 01时45分21秒

相关内容