Конфигурация за използване на Mercurial с Bitbucket зад прокси за пренаписване на сертификат?

Опитвам се да вляза в BitBucket от работа. Единственият достъп до интернет е чрез удостоверяващ HTTP прокси, който проксира http на порт 8080 и SSL на порт 8070. Този прокси извършва атака "човек по средата" на SSL връзки, браузърите могат да създават HTTPS връзки към интернет само поради инсталирането на фалшив сертификат на Websense на всички клиенти.

Мога да се свържа с BitBucket с помощта на Git, но не и с Mercurial. Използвам Mercurial версия 2.0.2.

С Git използвам следната конфигурация в .gitconfig

[user]
    name = Firstname Lastname
    email = [email protected]
[http]
    proxy = http://name:[email protected]:8080

И може да клонира хранилище със следната команда

D:\MercurialTesting>git clone http://[email protected]/Firstname_Lastname/bb102repo.git test1
Cloning into 'test1'...
Password for 'bitbucket.org':
remote: Counting objects: 3, done.
remote: Total 3 (delta 0), reused 0 (delta 0)
Unpacking objects: 100% (3/3), done.

D:\MercurialTesting>

С добавянето на тази настройка на конфигурацията

[http]
    sslverify = false

Мога също да клонирам хранилището чрез https url https://[email protected]/Firstname_Lastname/bb102repo.git

Използването на Mercurial обаче е различна история. Използвайки следната конфигурация в mercurial.ini

[http_proxy]
host = nnn.nnn.nnn.nnn:8080
user = [email protected]
passwd = password

Mercurial ще има достъп до моя собствен Mercurial сървър у дома без проблем.

D:\MercurialTesting>hg --debug clone http://nnn.nnn.nnn.nnn/hg/Workspaces/Test1
using http://nnn.nnn.nnn.nnn/hg/Workspaces/Test1
proxying through http://nnn.nnn.nnn.nnn:8080
sending capabilities command
http authorization required
realm: Mercurial Repositories
user: username
password:
http auth: user username, password *******
destination directory: Test1
query 1; heads
sending batch command
http auth: user username, password *******
requesting all changes
sending getbundle command
http auth: user username, password *******
adding changesets
changesets: 1 chunks
add changeset 711ff2c6f5b2
changesets: 2 chunks
add changeset 9034b963b4c1
. . .

Използването на абсолютно същата конфигурация и опитът за достъп до BitBucket през Mercurial просто виси.

D:\MercurialTesting>hg --debug clone http://bitbucket.org/Firstname_Lastname/bb101repo
using http://bitbucket.org/Firstname_Lastname/bb101repo
proxying through http://nnn.nnn.nnn.nnn:8080
sending capabilities command
abort: error: A connection attempt failed because the connected party did not properly respond after a period of time, or established connection failed because connected host has failed to respond

D:\MercurialTesting>

Използвайки същата конфигурация със SSL чрез url https://bitbucket.org/Firstname_Lastname/bb101repo Mercurial виси точно по същия начин. По време на този процес Wireshark не открива никаква мрежова активност.

Промяната на настройките в Mercurial.ini, за да съответстват на порта, през който проксито обслужва SSL, няма ефект. Задаването на променливата на средата http_proxy няма значение, но настройката на променливата на средата https_proxy променя изхода напълно. Задаването на https_proxy и добавянето на --insecure към извикването на командата hg води до:

D:\MercurialTesting>hg --debug clone http://bitbucket.org/Firstname_Lastname/bb101repo --insecure
using http://bitbucket.org/Firstname_Lastname/bb101repo
proxying through http://nnn.nnn.nnn.nnn:8080
sending capabilities command
warning: bitbucket.org certificate with fingerprint 79:ce:0d:30:b0:17:29:6a:d1:9f:dd:d3:62:80:70:28:5e:9f:c2:e3 not verified (check hostfingerprints or web.cacerts config setting)
http authorization required
realm: Bitbucket.org HTTP
user: Firstname_Lastname
password:
http auth: user Firstname_Lastname, password ***
warning: bitbucket.org certificate with fingerprint 79:ce:0d:30:b0:17:29:6a:d1:9f:dd:d3:62:80:70:28:5e:9f:c2:e3 not verified (check hostfingerprints or web.cacerts config setting)
abort: HTTP Error 502: Success

D:\MercurialTesting>

И сега Wireshark открива извършващ се обмен между моята работна станция и прокси сървъра. Това, което намирам за най-объркващо обаче, е, че няма никаква разлика на какво задавам https_proxy, hg винаги използва настройката за http прокси от Mercurial.ini и произвежда същия изход по-горе, независимо дали аз задайте https_proxy на правилните данни за SSL проксито или за да завършите боклука. Единствената разлика е, че ако променливата на средата https_proxy изобщо не е зададена, тогава hg просто виси, както е описано по-горе.

Форматите за https_proxy, които опитах, включват всички варианти на:

https_proxy=ip.ip.ip.ip:8070
https_proxy=ip.ip.ip.ip:8080
https_proxy=username:[email protected]:8070
https_proxy=username:[email protected]:8080
https_proxy=http://ip.ip.ip.ip:8070
https_proxy=http://ip.ip.ip.ip:8080
https_proxy=http://username:[email protected]:8070
https_proxy=http://username:[email protected]:8080

Резултатите са едни и същи, независимо на какво го настроя.

Така че въпросите, за които наистина мога да се възползвам от помощ, са:

Как така имам достъп до моите хранилища на Mercurial у дома, но не и в BitBucket?

Как мога да получа достъп до BitBucket с Git, но не и с Mercurial, използвайки същата конфигурация?

Някой има ли идеи как мога да накарам това да работи или какво мога да тествам след това?


person Neutrino    schedule 24.01.2012    source източник
comment
Истинският канал за поддръжка на Mercurial е пощенският списък: [email protected]. Моля, изпратете имейл там с въпроса си.   -  person Martin Geisler    schedule 24.01.2012
comment
Сблъсквал съм се с подобен проблем, но при свързване с BitBucket, удостоверяването е неуспешно за моето хранилище, дори когато ЗНАМ, че паролата е правилна.   -  person MattGWagner    schedule 21.02.2012
comment
Разрешавали ли сте някога това? Сблъсквам се със същия проблем през всичките тези години...   -  person kayleeFrye_onDeck    schedule 12.02.2016
comment
Не, не го направих. Това, което направих, беше, че вместо да използвам BitBucket, хоствах личните си проекти на Fogbugz и Kiln. Kiln предоставя инсталация на инструменти, която има предварително конфигурирана инсталация на TortoiseHg, която оттогава работи добре за мен. Функциите за управление на проекти на Fogbugz също са доста приятни и цялата им система е напълно безплатна за един потребител.   -  person Neutrino    schedule 12.02.2016


Отговори (3)


Също така се свързвам чрез прокси към bitbucket. Тъй като настройките ми не работеха според очакванията, намерих този запис SO.

Забелязах, че ако използвам параметри на командния ред, тогава всичко работи.

hg --config http_proxy.host=192.168.1.1:8080 --config http_proxy.user=Vad1mo --config http_proxy.passwd=secret clone https://bitbucket.org/Vadimo/test

От друга страна същите записи в Mercurial.ini не работят.

[http_proxy]
host = 192.168.1.1
port = 8080
user = Vad1mo
passwd = internet 

Случайно открих малката разлика между CMD и ini. В CMD портът е постфиксиран към хоста. В ini файла това е нов запис.

Промяната на mercurial.ini за постфикс на порта към хост като на командния ред реши проблема.

[http_proxy]
host = 192.168.1.1:8080
;port = 8080
user = Vad1mo
passwd = internet 

Може би това също ще ви помогне.

между другото моята hg версия е 2.6.3

person Vadimo    schedule 12.07.2013

Сблъсках се с подобен проблем с проксито на моята работа - всъщност почти идентичен.

Заобиколих проблема досега, като зададох http_proxy в mercurial.ini и след това се свързах с BitBucket чрез техния HTTP адрес hg.io.

Например моето хранилище на https://bitbucket.org/mattgwagner/mattgwagner.com може да бъде достъпен чрез http://hg.io/mattgwagner/mattgwagner.com. Разбира се, това ще изпрати вашата парола и връзка в обикновен текст, но поне ми позволи да се свържа.

Това беше по-полезно за мен, когато изтеглях проекти с отворен код, хоствани на BitBucket за моя употреба.

Mercurial.ini
[http_proxy] host = 192.168.1.155:8080
no =
user = domainUsername
passwd = pass

person MattGWagner    schedule 16.04.2012
comment
Благодаря за информацията. Наистина се надявах това да го оправи, но никаква радост. Този URL път работи от вкъщи, но не и на работа. Залепете го в браузър и BitBucket съобщава „CSRF проверката е неуспешна. Заявката е прекратена.' Търсенето в Гугъл показва, че грешката може да е причинена от несъответствие на заглавката на препращащите URL адреси, въпреки че не блокирам заглавката на референтите с моя браузър. Не съм сигурен дали половината ни мрежови проблеми са причинени от конфигурация за мрежова сигурност или просто мрежовият ни екип е невеж. - person Neutrino; 17.04.2012

Можете ли да излезете чрез ssh? Bitbucket поддържа ssh достъп и вашият прокси няма да заличи това, ако е разрешено.

person Ry4an Brase    schedule 10.04.2012
comment
За съжаление не. Цялата мрежа е заключена по-здраво от един комар. - person Neutrino; 11.04.2012
comment
Тъй като можете да посетите stackoverflow.com, може би можете да се свържете с careers.stackoverflow.com. Това може да помогне при проблема със защитната стена. ;) - person Ry4an Brase; 11.04.2012