Accessing Internet after update and telemetry was disabled - visual-studio-code

I just installed the VScode Windows zip version with vim extension on Windows 7. For privacy I disabled these options in the settings.json file:
{
"update.channel": "none",
"telemetry.enableTelemetry": false,
"telemetry.enableCrashReporter": false
}
But VScode is still connecting to different MS Internet sites at startup:
191.238.172.191 Microsoft Informatica Ltda (br)
40.114.241.141 Microsoft Corporation (MSFT)
40.77.226.250 Microsoft Corporation (MSFT)
How can I disable VScode connecting to sites in the background I don't want to connect to?

I ran the program with Wireshark on linux and I can confirm the background connections.
The first address is for marketplace.visualstudio.com, so it's probably used for extension update checks or similar? If you use extensions you might want to leave it as it is.
The last addresses are most likely related to telemetry. Visual Studio Code makes several DNS lookups even though the telemetry and updates are "disabled". You can try to add some of those DNS names to your hosts file in order to prevent the connections, but keep in mind that doing so might have side effects on your system functionality as Windows uses them for other (telemetry and such) purposes. Here are a few of the DNS lookups I was able to trigger with a small testing, there are likely many more:
0.0.0.0 dc.services.visualstudio.com
0.0.0.0 dc.trafficmanager.net
0.0.0.0 vortex.data.microsoft.com
0.0.0.0 weu-breeziest-in.cloudapp.net
I share your concerns. Having 20 years of experience with Microsoft I'm very frustrated and scared of using any of their products. The license for Visual Studio Code does not fill me up with confidence either. I'm not really surprised that "opting out" of telemetry does not even actually disable it.
I do like Visual Studio Code more than Atom and instead of downloading it from Microsoft, I cloned the original vscode repository (which is MIT licensed base product for the Visual Studio Code) and installed it instead. It doesn't seem to connect to Internet immediately when I start typing. Unfortunately, I haven't figured out how I can easily update and install extensions to vscode, so I might have to return to Atom eventually. I wish someone with more interest and time on their hands would fork a telemetry free vscode with marketplace functionality and share the binaries for the rest of us.
Update:
I raised an issue (#16131) about this. Looking at the total amount of open issues (~3000) on vscode I don't expect it to be solved anytime soon. For the time being you should block at least vortex.data.microsoft.com and dc.services.visualstudio.com in your hosts file. Blocking those two won't affect the usage of marketplace or any other necessary functionality. Blocking them seems to cease most Internet traffic for Visual Studio Code 1.7.2 (which might change in future versions).
What also worries me is that even though the data sent to vortex is encrypted, Visual Studio Code actually sends details about your machine and OS unencrypted plain text (via HTTP POST) to dc.services.visualstudio.com. (Note that I didn't yet file an issue about that).
Update 2:
According to the official reply I got for the issue #16131, Visual Studio Code was sending the information to Microsoft that the user had opted out from telemetry. A bit odd choice to send telemetry about the user not wanting any telemetry, but they said that they will stop doing it in the future. I appreciate their honesty with this matter.
seanmcbreen:
We use our telemetry to help understand how to make the product better – in fact a good example of this right now is some work we are doing to improve performance. So, we appreciate it when users opt to send us telemetry.
That said there are times when people don’t want to do that and you bring up a good point – today we continue to send events stating that a user has opted out and nothing else i.e. no usage data is sent. Here is the test to ensure that is all we send...
https://github.com/Microsoft/vscode/blob/master/src/vs/platform/telemetry/common/telemetryService.ts#L103
But we don’t need to do that and I don’t think it’s what you expect as a user – so we will stop sending anything i.e. even the opt out event 😄 Look for a change there soon.
Thanks for bringing this to our attention and I hope you enjoy working with VS Code.

Check also the version of Git you are using with VSCode.
Starting Git 2.19 (Q3 2019), possible telemetry can be sent from IDE/products using Git.
See commit 7545941 (13 Jul 2018) by Jeff Hostetler (jeffhostetler).
Helped-by: Eric Sunshine (sunshineco), René Scharfe (rscharfe), Wink Saville (winksaville), and Ramsay Jones (jeffhostetler).
(Merged by Junio C Hamano -- gitster -- in commit a14a9bf, 15 Aug 2018)
Junio C Hamano, official maintainer for Git, added in this thread:
Transport (or file) can stay outside the core of this "telemetry" thing---agreeing on what and when to trace, and how the trace is represented, and having an API and solid guideline, would allow us to annotate the code just once and get useful data in
a consistent way.
Ævar Arnfjörð Bjarmason added here:
To elaborate a bit on Jeff's reply (since this was discussed in more
detail at Git Merge this year), the point of this feature is not to ship
git.git with some default telemetry, but so that in-house users of git
like Microsoft, Dropbox, Booking.com etc. can build & configure their
internal versions of git to turn on telemetry for their own users.
There's numerous in-house monkeypatches to git on various sites (at
least Microsoft & Dropbox reported having internal patches already).
Something like this facility would allow us to agree on some
implementation that could be shipped by default (but would be off by
default), those of us who'd make use of this feature already have "root"
on those user's machines, and control what git binary they use etc,
their /etc/gitconfig and so on.
So, in addition of Microsoft/vscode issue 16131, we will have to monitor how VSCode uses Git in the future, since Git will offer a telemetry framework, for editors to use if they choose to.
With Git 2.25 (Q1 2020), We have had compatibility fallback macro definitions for "PRIuMAX", "PRIu32", etc.
But we did not for "PRIdMAX", while the code used the last one apparently without any hiccup reported recently.
The fallback macro definitions for these <inttypes.h> macros that must appear in C99 systems have been removed.
See commit ebc3278 (24 Nov 2019) by Hariom Verma (harry-hov).
(Merged by Junio C Hamano -- gitster -- in commit e547e5a, 05 Dec 2019)
git-compat-util.h: drop the PRIuMAX and other fallback definitions
Signed-off-by: Hariom Verma
Helped-by: Jeff King
Git's code base already seems to be using PRIdMAX without any such fallback definition for quite a while (75459410edd (json_writer: new routines to create JSON data, 2018-07-13), to be precise, and the first Git version to include that commit was v2.19.0).
Having a fallback definition only for PRIuMAX is a bit inconsistent.
We do sometimes get portability reports more than a year after the problem was introduced.
This one should be fairly safe.
PRIuMAX is in C99 (for that matter, SCNuMAX, PRIu32 and others also are), and we've been picking up other C99-isms without complaint.
The PRIuMAX fallback definition was originally added in 3efb1f343a ("Check for PRIuMAX rather than NO_C99_FORMAT in fast-import.c.", 2007-02-20, Git v1.5.1-rc1 -- merge).
But it was replacing a construct that was introduced in an even earlier commit, 579d1fbfaf ("Add NO_C99_FORMAT to support older compilers.", 2006-07-30, Git v1.4.2-rc3), which talks about gcc 2.95.
That's pretty ancient at this point.
[jc: tweaked both message and code, taking what peff wrote]
Signed-off-by: Junio C Hamano

Visual Studio 2019 - Block IP Addresses:
ServiceHub.IdentityHost.exe -------------------
13.69.65.22
13.69.65.23
13.69.66.140
40.114.241.141
51.140.6.23
117.18.232.200
152.199.19.161
65.55.44.109
devenv.exe ------------------------------------
13.107.5.88
88.221.230.45
104.69.107.218
104.81.67.220
104.88.48.82
104.107.176.162
104.214.77.221
117.18.232.200
152.199.19.161
23.198.79.63
13.69.66.140
PerfWatson2.exe --------------------------------
2.17.84.229
2.19.38.59
20.44.86.43
52.158.208.111
65.55.44.109
104.81.67.220
104.107.176.162
117.18.232.200
152.199.19.161
104.74.143.169
104.88.48.82
51.143.111.7
104.69.107.218
ServiceHub.VSDetouredHost.exe ------------------
117.18.232.200
152.199.19.161
104.74.143.169
2.19.38.59
vsls-agent.exe ---------------------------------
40.114.242.48
ServiceHub.Host.CLR.x86.exe --------------------
88.221.230.45
117.18.232.200
152.199.19.161
ServiceHub.RoslynCodeAnalysisService32.exe -----
117.18.232.200
152.199.19.161
ServiceHub.DataWarehouseHost.exe ---------------
117.18.232.200
BackgroundDownload.exe --------------------------
2.20.222.12
2.20.222.14
2.19.237.173
2.21.120.100
2.22.211.152
13.107.5.88
23.35.175.220
23.38.229.99
23.40.218.49
23.43.200.93
23.62.197.99
23.67.120.162
23.194.18.196
23.195.139.83
23.198.79.63
23.206.38.71
23.213.218.202
23.214.174.91
23.217.250.58
65.55.44.109
88.221.230.45
96.6.244.11
104.69.107.218
104.74.143.169
104.83.182.123
104.89.78.57
104.98.168.64
104.102.189.193
104.107.176.162
104.111.238.86
104.119.235.204
104.126.110.182
104.214.77.221
104.126.245.85
117.18.232.200
152.199.19.161
172.227.168.22
VSIXAutoUpdate.exe ------------------------------
117.18.232.200
23.203.81.132
65.55.44.109
184.87.56.190
152.199.19.161
104.89.78.57
104.102.189.193
Microsoft.ServiceHub.Controller.exe -------------
13.69.65.23
13.69.65.22
152.199.19.161
13.69.66.140
ServiceHub.SettingsHost.exe ---------------------
152.199.19.161

Related

exosip always answer twice when receive invite event

I'm new in sip and use exosip to develop a sip gateway.
I found my gate way is always send answer twice, but the log in my program just print once.
I don't know what happened and how to fix this problem.
UPDATE:
I update my version to 5.2.0, but the problem still exists.
Also, I found there exists duplicated RTP connections:
The question most bothers me is that audio packets are duplicated, which makes high packet loss rate:
In version 5.1.2, there was a major rewrite of DNS, UDP, TCP and TLS management. The rewrite was required to maximize performance and to reach the same results with select and epoll implementations. Those changes introduced issues resolved in incremental steps and 3 versions were published in a row: exosip 5.1.2, 5.1.3 and finally 5.2.0
Your issue was fixed only in 5.2.0 with this ChangeLog line:
* fix duplicate packets for TCP and TLS when several outgoing NICT are happening at the same time [since 5.1.2]
The git fix is this one:
https://git.savannah.nongnu.org/cgit/exosip.git/commit/?id=1fdc54ed38eaf5155f5702240586c472f2cc73d4
You can read the full ChangeLog here for details.
There as been 3 commits since 5.2.0 in the git which may be nice to have. access git here
Make sure you also use latest osip 5.2.0 or access git here. There was only one additionnal commit which is also interesting.
NOTE: In my own tests: I have seen only retransmission of REQUESTs, but I would not be surprised if the bug was also affecting ANSWERS? If you use already the latest version, please write me a mail.

How to use Terminal API to listen to all terminal output in vscode?

I want to listen to terminal output from extension, such as tsc -w and catch the moment if the output contains similar text:
Found 1 error. Watching for file changes.
Or the error exit code or something like that. Is it possible to do with old API or Proposed API?
Tried:
terminal.onDidWriteData(data => {
console.log('onDidWriteData: ', data.trim());
});
It just outputs autogenerated rubbish like:
Windows PowerShell
Copyright (C) Microsoft Corporation. All rights reserved.
Looks like it is deprecated in insiders edition. Try using window.onDidWriteTerminalData:
window.onDidWriteTerminalData(event => console.log(event.data.trim()))
Reference
https://github.com/microsoft/vscode/issues/78574
Unfortunately there is no way. There is an event API - window.onDidWriteTerminalData, however it is a "proposed" API which means it's only in the Insiders version of VSCode and you can't use it in a published extension. Basically you can't use it.
According to this comment and this comment although it is "proposed" never going to make it stable due to performance concerns.
As an alternative perhaps you could pipe tsc -w through another program that forwards stdout/stderr and listens for the trigger string. When it sees it it can notify your extension through some other means, e.g. writing a file that you watch or some IPC system.
Unfortunately the downside of that approach is that you can no longer associate the terminal with the VSCode instance, so it might not work if you have multiple VSCode instances running.

Is WinDbg's vertarget command always accurate?

I wonder because running it on a client's minidump it reports a different Windows version than the client repeatedly told me she had, and the version I'm being reported happens to be exactly the same version I'm running WinDbg on.
So I wonder, can vertarget always be trusted (and clients not) or the information it relies on may be absent with some dump generation options and when it is it reports the version WinDbg is currently running on, or maybe just some default that happens to coincide with my OS version?
I'm using WinDbg 6.12.
In all my cases so far, vertarget has been correct and the customer/client made a mistake - and vertarget is one of the commands I use for every dump, exactly for the purpose of checking if the dump contains what I need.
But perhaps, things can potentially go wrong here as well, so let's evaluate some options:
vertarget also reports debug session time and system uptime. Do those also match your system? Reboot your system in order to get a low system uptime and check again. Is it still your PC's uptime?
vertarget also reports the number of CPUs. Does that number match your number?
Get a virtual machine which does not have your OS, e.g. one from Modern.IE (Microsoft). Copy WinDbg and the dump to the VM and check the output of vertarget again.
WinDbg 6.12 is a bit old. Do newer versions (6.2.9200 / 6.3.9600 or even 10.0) provide the same information or was there a bug fixed already?
And even check some other information:
Is it a dump of the correct application? Use | (pipe)
Is it a dump of the version you are expecting? Use lm vm <exename>
Does it have the flags which can be expected for the method used for taking the dump? Use .dumpdebug.
Other than that I observe (not representative) that many client OS version dumps (Windows 7, 8, 8.1) have all latest service packs installed, while administrators seem to follow the "never change a running system" approach for server OS (Windows Server 2012, R2). So it might just be a coincident.

Simple push/pull between two "client" repositories to share changes

I'm in the process of more correctly implementing Source Control via Mercurial at work and I've run into a situation. My environment is two programmers with a Server and approx 4 dev computers. There are our 2 Office desktops where the majority of the code writting happens. And then there are 2 laptops used in the Labs for testing and debugging.
Previously, we had just been operating over the network; the code projects lived on the server and both my office and the lab laptop opened the files over the network. Yeah, I know it wasn't the best of ideas, but we made it work. Moving to a more correct model of DVCS with local repos presents with me with a problem: How do I get my code updates from my Office where I was typing to the Lab so I can program an actual chip? I feel like this level of changes (10, 20, 50, maybe even 100 little changes over the course of a day of development) doesn't need to go through the Server. Personal opinion is that commits to the Server should be reserved for when I'm actually ready to share what I have with others... not necessarily finshed with the project, just ready to share where I'm at.
Do I have to push to the Server and then pull to the Laptop everytime?
Can I just push/pull back and forth between my Office and the Lab laptop repos? How would I set that connection up?
Under the assumption that the "Server" is CVCS-emulation in DVCS environment (i.e push target|pull source for all data exchanges exclusively) and "always working single branch" antipattern not used:
Each Dev-host work with at least two named branches: personal (for WIP) and shared (merge-target) "default". WIP have to be pushed to Server, every other host Sync local repository with the whole Server's repository (but "authoritative source" is only default branch)
Pure DVCS-model
Except "Server" as default path, each Dev-host have 3 additional entries for other Dev's workplaces and pull-only model used for simplicity (no additional ACL and rules for pushes). I.e. (with human's communication) local http-server (hg serve) activated on source(s) on demand and on target developer hg pull ANOTHERDEV. Source server can' be stopped after it. Personal named branches isn't bad idea in this case also
Note: `hg serve can be always enabled on all 4 dev-hosts, combined pull command (pull 3 another repos) xan be defined as alias on every host and used when needed, without additional negotiation

TFS Source Control returns HTTP Code 302 with remote user

I have a remote developer connected to my TFS via the internet. When he attempts to do a GET from source control, he fails to get a number of files with error messages as this:
D:\CaseTrakker\CaseTrakker_v6_0\CaseTrakker\CaseTrakker.ObjectModel\Framework\Factories\Value\LookupValueViewModelFactory.cs: Please contact your administrator. There was an error contacting the server.
Technical information (for administrator):
HTTP code 302: Moved Temporarily
This does not happen for all files, but for many, and repeated retries does not resolve it. I am at a complete loss.
Possibly germane, the way that I have published my TFS is to set up a rule in my firewall to route requests targetting http://publicserver:8080/tfs to http://internalserver:8080/tfs. Since this error seems to have to do with redirection, that might be some or all of the issue.
Thanks in advance for any assistance.
David Mullin
IMA Technologies
Might be worth getting the external developer to upgrade to the latest Update 3 CTP of VS 2012 as there was a fix in it to handle retries better on downloads.
However, you'll probably have more luck if you configure it so that your TFS server is accessible over the same fully qualified domain name both internally and externally (internally resolving to the internal IP - externally resolving to your external IP). Check out this word document for more information (http://www.christiano.ch/common/documents/Exposing_Team_Foundation_Server_to_the_Internet.docx) or take a look at the Pro TFS 2012 book.