Crash Reporting

[schnappi]

Debating whether or not to enable crash reporting. Do not recall if the option allows viewing of something similar to what might be sent like usage reporting.

If a crash report got into the hands of a bad actor is there any information that one might want to be concerned about? Basically what is the worst information a bad actor could gain from a crash report?

Would like to enable the feature, so am in no way against it, just want to check what is being consented to being send.

[Catfriend1]

Hi,

Here is an example what is sent: https://docs.syncthing.net/users/crashrep.html It’s pretty anonymous, if you consider your IP is known by a lot of websites and services nowadays “normally”.

[Nummer378 (Max)]

[Poll] The sending of crash data

We will be including crash reporting soon. The way it will work is that when a crash (“panic” usually, in Go parlance) is detected the Syncthing version and backtrace is reported to some server, where it’s stored and aggregated. The data that will be sent looks like this: 07:48:24 INFO: syncthing v1.1.4 "Erbium Earthworm" (go1.12.5 darwin-amd64) teamcity@build.sycnthing 2019-05-21 20:36:38 UTC Panic at 2019-05-22T07:48:25+02:00 panic: interface conversion: *pfilter.FilteredConn is not net.Conn:…

Automatic crash reporting

Can we talk about this? Can we make it opt-in instead of opt-out? Can we have the election put on the settings page instead of the advanced configuration page? I’m happy to regularly answer questionnaires–I just don’t want developers (or anyone else) under my hood, if I can avoid it. Crossing my fingers…

Crashlog/Automatic error log sending to dev. team #959

Hi, The changelog tells us about the new enhancement Automatic error log sending to dev. team While this is probably great for the devs, as a user, I’m missing a way to see what precise content and when logs were sent. I remember reading the docs a month ago or so, (https://docs.syncthing.net/users/crashrep.html + https://docs.syncthing.net/dev/crashrep.html#crashrep-dev) where we all can read a generic text, what could be send off our machines to the devs, but how can we take a look at the d…

Basically, just leave it on (dismiss the message).

There’s currently a possiblity that a crash report includes minor personal data (e.g folder names), but the team is working on removing that, so that crash reports are free of any non-development data (see here for details).

[sisa]

Excuse me, but did I understand correctly?

Foldernames are sent via Crashreports?

Wow… this would be very disapointing and syncthing -if true- looses a lot of its trustfulness.

So, contributing via crashreports will bare the companies/user file-/folderstructure and some other protection deserving information (lead out of this folder-/filenames)?

[calmh (Jakob Borg)]

The panic message is shared, and sometimes that contained more info than we expected. Folder names/IDs have been removed since (see commits on the linked issue, also some other that changes a panic to a warning). There are still some leaks when an error causes a panic and the error includes path information. A typical example is when the database flakes out completely due to an I/O error or full disk, with a message like can't write to /home/jb/.config/syncthing/index-0.14.0.db. We’re working on removing those as well.

[imsodin (Simon)]

After this anything left should be gone: https://github.com/syncthing/syncthing/pull/5912 (mistakes are obviously possible).

[rkfg]

Would be also good to remove the timezone from the report. It’s not really needed for debugging but it provides some redundant information, for example if the user is behind VPN that terminates in another country. This timezone can hint where the user really are. Just use UTC+0 everywhere.

[calmh (Jakob Borg)]

I agree there is no need to record the time zone. That said, given that we don’t have or keep any other user identification (including IP), there’s not much to correlate to. The time zone by itself is hardly enough to identify an individual.