无法下载依赖项 [英] Can not download dependencies
问题描述
当我输入command go build时，我有一个项目与bitbucket上的私人存储库有多个依赖关系.我收到此错误
I have a project with several dependencies from private repositories on bitbucket when I type command go build . I get this error
无法识别的导入路径"bitbucket.xxx.xx/xx/x" x509:未知授权机构签名的证书
unrecognized import path "bitbucket.xxx.xx/xx/x" x509: certificate signed by unknown authority
我尝试了一些事情，例如添加令牌
I have tried several things such as adding token
git config --global http.extraheader令牌
git config --global http.extraheader token
配置为ssh
git配置--global url."git@bitbucket.org:".代替" https://bitbucket.org/"
，但是它不起作用.
推荐答案
关于使用HTTPS URL，请注意，HTTP传输可能存在分配器/取消分配器不匹配的问题，已通过Git 2.25(2020年第一季度)进行了纠正.
Regarding using an HTTPS URL, note that HTTP transport had possible allocator/deallocator mismatch, which has been corrected, with Git 2.25 (Q1 2020).
因此，如果您使用的是Git 2.24，则http.extraheader还是行不通的.
So if you were using Git 2.24, http.extraheader would not have worked anyway.
请参见提交4d17fd2 (2019年11月6日)由 Junio C Hamano-gitster-在
See commit 4d17fd2 (06 Nov 2019) by Johannes Schindelin (dscho).
(Merged by Junio C Hamano -- gitster -- in commit bad5ed3, 01 Dec 2019)
remote-curl:使用自定义分配器打开http.extraHeader签名人:Johannes Schindelin
在 93b980e58f5 ("http:将xmalloc与cURL一起使用"， 2019-08-15，Git v2.24.0-rc0-合并在第3批)中，我们开始要求cURL使用xmalloc()，如果已编译如果使用nedmalloc，则意味着与系统隐含了一个不同的分配器.
In 93b980e58f5 ("http: use xmalloc with cURL", 2019-08-15, Git v2.24.0-rc0 -- merge listed in batch #3), we started to ask cURL to use xmalloc(), and if compiled with nedmalloc, that means implicitly a different allocator than the system one.
这意味着cURL的所有分配和发布现在_need _都可以使用该分配器.
Which means that all of cURL's allocations and releases now _need_ to use that allocator.
但是，http_options()函数使用slist_append()添加任何已配置的额外HTTP标头_before _要求cURL使用xmalloc()，并且http_cleanup()会释放它们_afterwards_,，即存在自定义分配器中，cURL会尝试使用错误的分配器来释放内存.
However, the http_options() function used slist_append() to add any configured extra HTTP header(s) _before_ asking cURL to use xmalloc(), and http_cleanup() would release them _afterwards_, i.e. in the presence of custom allocators, cURL would attempt to use the wrong allocator to release the memory.
天真地解决此问题会将调用移到curl_global_init() _before _解析配置(即在调用slist_append()之前).
A naïve attempt at fixing this would move the call to curl_global_init() _before_ the config is parsed (i.e. before that call to slist_append()).
但是，这不起作用，因为我们_also _解析配置设置http.sslbackend，如果找到，请调用curl_global_sslset()，必须在curl_global_init()之前调用 ，有关详细信息，请参见: https://curl.haxx.se/libcurl/c/curl_global_sslset.html
However, that does not work, as we _also_ parse the config setting http.sslbackend and if found, call curl_global_sslset() which must be called before curl_global_init(), for details see: https://curl.haxx.se/libcurl/c/curl_global_sslset.html
因此，让我们改为使配置解析完全独立于cURL的数据结构.顺便说一句，这删除的行多于引入的行，这很不错.
So let's instead make the config parsing entirely independent from cURL's data structures. Incidentally, this deletes two more lines than it introduces, which is nice.
对于自签名证书，全局禁用SSL验证可能会被视为安全隐患，应仅在测试时实施.
For self-signed certificate, disabling SSL verification globally might be considered a security risk and should be implemented only for testing.
使用GIT_SSL_CAINFO 引用自签名证书更为安全.
Referencing the self-signed certificate by GIT_SSL_CAINFO is more secure.
这篇关于无法下载依赖项的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
