Hey, just saw https has been disabled in the official app since 0.10.18. (https://github.com/syncthing/syncthing-android/commit/1f82ec0fc6096d6694ae75ccaca5afcf09088581 ) Come on, instead of arguing about reviews merge Syncthing Forks solution which keeps https REST connection between the app and native if security is important.
1 Like
Yeah, that just seems like a horrible decision, one that actually introduces a security vulnerability. Now any app can just start listening on port 8384 and wait for the Syncthing app to start to get the API key. Then it can let Syncthing start, and use the API key to make any changes it wants, like add new devices, which would let it read and write data to all Syncthing folders.
For reference, syncthing-fork disables TLS on old Android versions, but keeps it enabled on supported versions. That is not ideal because it still leaves some devices vulnerable, but much better than disabling TLS completely.
Sorry @AudriusButkevicius I was giving you the benefit of the doubt, but now I really feel like the app would be in better hands with @Catfriend1 as maintainer.
Edit: The problem is not mainly about making a change to disable TLS. The problem is with arguing that code reviews are important for security, and then quietly merging and releasing something that obviously makes security worse, without any review at all.
How exactly was TLS preventing an app starting on the same port and getting the API key before?
There was no certificate validation, so this change does not make the security any worse.
If we want to rave and scream just for the sake to make me look bad, without actually understanding implications of the change, go ahead I couldn’t care less.
I have no interest in maintaining the app, nor did I want to spend my evening removing TLS and fixing builds.
Yes, it is hipocrate of me to merge my own changes and then demand reviews of others, but as we all agreed there are no maintainers, so I wouldn’t expect reviews.
I don’t want to spend any more than the 40mins I had on this (ideally I would not spend any time on this at all).
If you are so fussed about it, let me revert it and let’s just tell people to fuck off.
Also, my intentions to remove TLS were loud and clear in the ticket some time before the actual, so you could have objected that earlier. Now it seems you just came around when the change was done just for the sake of pouring dirt.
@Nutomic: I’ve just looked at the SyncthingTrustManager class which I hadn’t to fiddle before. Is that class there to validate Syncthings local https certificate?
I’ve reverted my change, and in progress of pushing out beta2. I did fuck up here, which probably means I should stay away from android all together and just let shit rot.
Hey guys, I was here to just thank you all for all your hard work and this great community, but as I see there are a lot of masculine discussions in the background o_O I hope you all get together and keep working on this great community which you have build. I’m using the syncthing on my android phone and pc and suggested it to all my family and friends ^^
You are creating a beautiful, easy to use and secure possiblity to synchronise everything for all the world.
Thank you all for your hard work.
Best wishes from germany (excuse my bad english, please 
) Christina.
8 Likes
Good that we agree here. Can we please make @Catfriend1 maintainer for the Android app then?
@Catfriend1 Yes, it verifies that the certificate sent by the Syncthing API matches the certificate file in the config folder. Precisely to prevent the attack of another app binding on port 8384 and getting the API key.
I’ve sent invitations / tweaked permissions. Let’s look at the new permanent structure later.
1 Like
Who is in charge of the GooglePlay account?
Thanks for the invitation. Before starting the work on the official I’d like to write up a suggestion how we could do merge and release management. I’ve already had interesting chats about this with @capi and @imsodin, got contacted yesterday by @Zillode. And of course, I’d like to do better in working together with Audrius during reviews. What I would intend to bring up first is the fix for the TLS problem. (Thanks @Nutomic for shedding light on this) From my research, is it okay to force https on all Android OS except 4.4 and 7.0? Another dev told me that those Android’s miss some elliptic curves to do tls 1.2 with strong ciphers.
From my research, is it okay to force https on all Android OS except 4.4 and 7.0? Another dev told me that those Android’s miss some elliptic curves to do tls 1.2 with strong ciphers.
Just my 50 cents on this, may be invalid since I don’t know the context of this, but: TLS 1.2 has a lot of secure cipher suites which do not require any elliptic curves. In the web ECDH/ECDSA is common, but standard Diffie-Hellman with RSA has a very broad compatiblity too. I’ve no idea if you use elliptic curves in the certificates or so, but not using TLS 1.2 on an Android 7 platform seems like a really bad idea.
1 Like
I think the issue is that to implement TLS 1.2 you need to implement those cipher suites, so the implementations that don’t then also cannot advertise TLS 1.2 compatibility. Which we require, so then the handshake fails.
But Android is officially supporting TLSv1.2 since Android 5.0 (API level 21) [https://developer.android.com/about/versions/android-5.0-changes#ssl]. I understand that on KitKat/4.4 the support for more recent TLS is unoffical and varying between vendors so I see the reason on older Androids. But I don’t understand what the issue with Android 7 is? The market share for Nougat is quite high, that’s what got my attention.
I have no idea.
Lets continue the TLS1.2/https related discussion here:
“Masculine discussion” is as you’ll find a lot of developers here being men, just as is in many places that deal with code, so it’s likely a bit biased. Nevertheless women are of course not expcluded to participate and are welcome any time to contribute. So feel free to drop in.
Regards
Don
1 Like
I believe the reference is to conversation that’s conducted as though it were battle, where the objective often seems as much to be to support one’s ego or damage the other participant’s as it is to reach a mutual understanding. There is a correlation between men and conducting conversations in such a way, but it’s by no means absolute. It’s well worth making a conscious effort to reduce it, because it’s usually not useful to achieving an objective.
3 Likes
Absolutely! If I’m correct it was Bill Gates who once said “Bash things, not people”. Nevertheless, even if you do so, there are people who have a problem (or even a inability) separating things from their own person and start mixing it up, projecting critics on things, ideas and stuff onto their own person. Or, despite being very high in rank, they have some inferiority complex and try to offset it by attempting to dominate decisions, etc. If then they fail to enforce their opinion they could get really pissed. You’ll even find those kind of humans in the excutive suits of big companies, so this is a sort of a “global problem”. Even Linus Torvalds has the occasional attitude of a very rude (and maybe inapt) tone, scaring off developers and causing a lot of scuffle. See the discussions on the kernel developement of the past months.
Best practice (namely in OSS development) would be to have a fair and respectful discussion of what would be the desired direction in which to stear. By involving many people with different opinions what the users will need should quickly crystalize. Even if the outcome is different from one’s personal preferences this is not contemptuous, even then I added some value to the discussion which aim is the best to target.
But hey, of course this is sort of whichful thinking! People have their weaknesses (me too) and it’s often rather laborious to deal with that and find a compromise that fits most needs.
2 Likes