What does seen but not heard mean, can you explicitly explain why we dont meet that, which features cause that?
Which I’ve explained both here and on github and you’ve collectively stated does not fit the userbase you’re targeting. Doesn’t negate it.
You mean which you agree is ambigious. Stangely you refuse to simply say the documentation will be updated to reflect that? Or has that changed too?
Perfect. Why couldnt’ we have come to this ealier rather then accuse me of being overparanoid and deny such a risk even exists? It was my understanding syncthing would not work without a servername of “Syncthing” and some other headers I found in another thread.
If you don’t want to talk about it then what is the point of this? You’re going to ban anyway. I mean, the thread is saved no matter how many times you guys update your posts.
Done with this thread anyway. Best of luck.
Noone has mentioned banning (except you). Please stop trying to make yourself a victim, and concentrate on the technical discussion here.
This thread could either lead to improvements in Synching’s behaviour and/or documentation, or it could lead to you storming off in a huff and the rest of us moving on with our lives. Which way it goes is largely down to you right now.
1 Like
It includes the sercurity part too, ie static keys /certs. Thus would not require disclosing anything.
Sure. I mean, I never said it shouldn’t. Only asked if it could and how.
RC. Doesn’t negate they are reported but sure.
I can’t explain what you refuse to understand so… no?
You misunderstand. Most of the discussion now is “he said this”, “I did not say that”. I am not 6 years old, and I am not very interested playing the who said what and who blamed who game.
I am here to discuss technical details, so let’s stick to that.
? You did, above.
The only thing that’s potentially bannable here is rudeness, and I doubt anyone wants to go down that path.
I’ll do no such thing 
Storming off that is, leaving sure. I’d hope your documents are at least semi updated, that is all I was after.
Cheers.
I don’t misunderstand… It’s called quoting(?) and you were frequently refering to things I never said.
Please clarify? In what way are there non-static keys or certs? Please give me specifics here.
OK. Do we want to have a discussion on whether usage reporting should be enabled on the rc, or perhaps whether the user should be better informed of this? I think there’s potentially a valid actionable point here.
I’m afraid I don’t understand what you mean by this. If there’s something from the bit of your initial post which you quoted just above and which I missed, please tell me what it is so we can discuss it.
Sure, perhaps you did say it somewhere, but I don’t follow every thread and I don’t read every comment. I’ve read what’s on this thread so far, and the only two techical points I saw were the ones I’ve tried to address above.
If you want to discuss some other points, collect a list of bullpoints of technical matters and I’ll do my best to answer why things are the way they are.
Yeah, perhaps the documentation does not state that it’s on by default for release candidates (I have not checked), but I don’t think we should pollute docs with beta behaviours. The docs are community maintained, if you think it should be improved and reworded, please file a pull request with your suggestions for discussion.
This is not documented, but it’s possible to run with any certificate you want (yet it might not be a good idea if the certificate has an expiry date in the near future, as updating the certificate would change the device id). Essentially, you’d have to set certName on each peer stating what they should expect the SNI to be. I still think it’s somewhat a pointless wish, as you can still connect to the socket and get the first message of the BEP protocol which would reveal device name and the fact that you are running syncthing.
Let me refer you to the Release Channels article which explains the difference between stable and candidate releases. It’s linked from the GUI, even. Specifically, the table is quite clear I think:
If you had opened the settings GUI on your RC build you would have seen this, which should be a hint to what’s going on:
If you don’t use the GUI, the console output is relevant:
There is also a discussion about certificates and device IDs on the documentation site. Entering “certificate” in the search box trivially brings it up, if you didn’t want to browse through the whole thing. There’s a lot of info you might like, and also this little nugget:
An advanced user could replace the
key.pemandcert.pemfiles with a keypair generated directly by theopensslutility or other mechanism.
I think you are the advanced user here. To use it you also need to set the certName of the device, as Syncthing will otherwise expect syncthing. This is documented here.
As for doing this to avoid someone seeing that you use Syncthing… Can I ask, what’s your threat model, exactly? That is, who or what are you protecting against? I used to work for a company doing DPI, and I can guarantee that the presence or lack of the string “syncthing” in the handshake doesn’t make any appreciable difference to how easy it is to recognize the traffic as Syncthing. I mean, it’s a nice courtesy that it’s there, but removing it is like trying to fool camera surveillance by changing your shoes. You’re still recognizably yourself.
2 Likes
Sounds like a couple of documentation updates, of some sort, are all that’s required to resolve this?
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.