Fogbugz integration Bug

[bastress]

So we have the FogBugz integration setup with Vault and thought it had been working at one point. However recently notice that only 10% of the check-ins seem to be linking back to FogBugz. After some investigation, it appears only the check-ins from visual studio to vault are being linked, and all check-ins from the Vault client are not. Investigating further we see that many of the links that were created in FogBugz from the Visual Studio Vault check-in are broken. It appears that the links have had the '&' encoded to '&' for all URL parameters.

Broken Example:
http://vault.com/VaultService/VaultWeb/ ... &Version=5

Working Example:
http://vault.com/VaultService/VaultWeb/ ... &Version=5

Can the Vault Client be fixed to properly post to FogBugz and the links fixed to encode the URL parameter data but not the parameters themselves?

EDIT....
Using Fiddler, it appears that the HTTPS handshake fails:

fiddler.network.https> HTTPS handshake to fogbugz.creditinfonet.com (for #9) failed. System.Security.Authentication.AuthenticationException A call to SSPI failed, see inner exception. < The message received was unexpected or badly formatted

Win32 (SChannel) Native Error Code: 0x80090326

Also I see it appears to be communicating via TLS1.0:

Version: 3.1 (TLS/1.0)
Random: 5B 74 3D A3 D1 6B B9 91 3B 26 D5 DB 58 00 44 43 3B BF B7 36 32 A9 BB A4 36 73 AC 21 F4 04 20 50
"Time": 10/13/2056 9:48:11 PM
SessionID: empty
Extensions:
server_name fogbugz.xxxx.com
elliptic_curves unknown [0x1D), secp256r1 [0x17], secp384r1 [0x18]
ec_point_formats uncompressed [0x0]
SessionTicket empty
extended_master_secret empty
renegotiation_info 00
Ciphers:
[C00A] TLS1_CK_ECDHE_ECDSA_WITH_AES_256_CBC_SHA
[C009] TLS1_CK_ECDHE_ECDSA_WITH_AES_128_CBC_SHA
[C014] TLS1_CK_ECDHE_RSA_WITH_AES_256_CBC_SHA
[C013] TLS1_CK_ECDHE_RSA_WITH_AES_128_CBC_SHA
[0039] TLS_DHE_RSA_WITH_AES_256_SHA
[0033] TLS_DHE_RSA_WITH_AES_128_SHA
[0035] TLS_RSA_AES_256_SHA
[002F] TLS_RSA_AES_128_SHA
[000A] SSL_RSA_WITH_3DES_EDE_SHA
[0038] TLS_DHE_DSS_WITH_AES_256_SHA
[0032] TLS_DHE_DSS_WITH_AES_128_SHA
[0013] SSL_DHE_DSS_WITH_3DES_EDE_SHA
[0005] SSL_RSA_WITH_RC4_128_SHA
[0004] SSL_RSA_WITH_RC4_128_MD5

Compression:
[00] NO_COMPRESSION

TLS1.0 and TLS1.1 have been turned off for all our servers. Communication must be done via TLS1.2


[edited out domain for security reasons]

[jclausius]

What version of Vault is in use?

For Vault 9 and earlier, HTTPS only supports SSL3 and TLS 1.0
For Vault 10, there is a different client to download that supports TLS 1.1 or TLS 1.2.


In regards to the URL, are those generated / displayed within FogBugz? Where do you see those URLs, as cannot find where they are generated by Vault. Are they perhaps generated by FogBugz after the Vault bug submission?

[bastress]

Hmm I was looking for a way to post a pic.
Well anyway we are using Vault 10. In FogBugz if you open a case and click on the Checkin link, a box pops up which says 'Checkins for Case #####'. There are two links in the box. one for VaultHistory.aspx the other link for VaultDiff.aspx. Links with more than one URL parameter are broken due to the html encoding.

[jclausius]

If you are using Vault 10, and can only connect through HTTPS using TLS 1.2 or TLS 1.1 there is a GUI client that can be used - http://download.sourcegear.com/Vault/10 ... .1.793.zip ... You can extract this over your existing GUI Client or extract and keep it in it's own folder.

In regards to the links back into Vault, it appears as those URLs are most likely be generated by FogBugz. If you can, please check with them to see why they are encoding the generated URLs. If they need any input from us, please let us know, and we'll assist with the issue as best as we can.

[bastress]

The Vault client you provided did indeed fix the TLS communication problem and is now posting to Fogbugz. Thank you. Now we just need to get the URL encoding problem fixed.

[jclausius]

If I'm understanding this correctly, I'm pretty sure those URLs are created / generated within FogBugz. Check with their support.

If they need any information from us on the integration, just let us know, and we'll provide them with whatever info they may need.

[bastress]

Using the TLS1.2 version...
Getting this error when executing the Vault.exe commands from PowerShell.

Unhandled Exception:
System.BadImageFormatException: Could not load file or assembly 'VaultClientOperationsLib, Version=10.0.0.736, Culture=neutral, PublicKeyToken=e372e94840f8a4d3' or one of its dependencies. This assembly is built by a
runtime newer than the currently loaded runtime and cannot be loaded.
File name: 'VaultClientOperationsLib, Version=10.0.0.736, Culture=neutral, PublicKeyToken=e372e94840f8a4d3'
at VaultCmdLineClient.VaultCmdLineClient.Main(String[] args)
WRN: Assembly binding logging is turned OFF.
To enable assembly bind failure logging, set the registry value [HKLM\Software\Microsoft\Fusion!EnableLog] (DWORD) to 1.
Note: There is some performance penalty associated with assembly bind failure logging.
To turn this feature off, remove the registry value [HKLM\Software\Microsoft\Fusion!EnableLog].

[jclausius]

Sorry, I didn't check to see if you needed the command line tool. This would be different too -
http://download.sourcegear.com/Vault/10 ... .1.793.zip

[bastress]

Thank you. Do we extract this overtop the vault folder where we extracted the last TLS1.2 client?

[jclausius]

I just ran a quick test, and it appears that replacing any files from the TLS GUI Client with files extracted from the TLS CLC has no ill effect. I was able to log in with both, and run a history query within each.