I was concerned about this much before this “controversy” unfolded. I was only casually looking for solutions back then but now I’m seriously/actually doing it.
Basically don’t trust syncthing-fork (or even syncthing if you want but I was mostly concerned about the forks/3rd-party stuff) and only share encrypted stuff - so even if there’s a leak (due to malice/incompetence/…) you are better protected (depending on your threat model ofc).
Setup:
Linux: Use gocryptfs to initialise/point to an encrypted dir (/path/ciphtertext) and fuse mount it to plaintext dir (/path/plaintext). Point syncthing to /path/ciphtertext
MacOS: use gocryptfs again - use macFUSE or whatever it’s called now, or use lima to run a linux VM and share ciphertext and plaintext dirs between host/guest.
Android: Use DroidFS - in its settings allow it to create the document provider mounts for plaintext that you can now see via your system-picker/file-picker.
Use syncthing to only sync the ciphertext dir. Since this is not a block-device encryption and per file encryption only the diff gets sync-d, just like it would with regular files. Now even if syncthing-fork or whatever goes rogue, it only touches encrypted stuff so it’s not that bad.
I use GrapheneOS (evident from the link above) so I additionally storage-scope it to just that root dir which contains encrypted files/dirs. Working OK so far.
The important thing to remember is that running any program on your device possibly exposes any data it can access. You might be pointing it to only /path/ciphertext, but if you don’t isolate the process from the rest of the system, it may just as well access /path/plaintext on its own. If running software with your regular user access privileges, you always need to trust it that much. The only protection for untrusted software is a strong sandbox enforced by the OS.
The part you quoted is for Syncthing-Fork, which is the Android app. Android already has the security/sandbox you are talking about. If you use GrapheneOS you can further use Storage-Scopes. This is the best we have got as far as I’m aware of and it’s pretty darn good so there’s little concern there.
Desktop OS however is a different story esp Linux - it’s the worst of the big 3 (MacOS, Windows, Linux) and ordinarily (or even with considerable effort) it’s a security nightmare. Other 2 are more secure but ofc a privacy nightmare. If it bothers someone they can use the sandboxing via VM compartmentalisation of QubesOS which is as good as it gets for Linux (well Xen) as of today that I’m aware of. Or much more easily but lower security would be running desktop Syncthing in a docker container and mounting the encrypted dir as a volume - this is actually what I use on Arch (an otherwise security nightmare but “fun” )
Anyway, trusting an offline app (droidfs/gocryptfs) is slightly easier for me and results are more easily inspectable (ie the encrypted folder only contains ciphertext/junk) than an online app going rouge.
@monozygote@acolomb If you want to continue your discussion, please, do so in a new thread. I want to be notified of new posts about the topic of this thread only. Thanks.
fair, but also I think (possibly incorrectly) this thread is already past its usefulness in that case:
Does anyone know why syncthing-fork is no longer available on Github?
General
It is available in Github now, there was a blackout briefly, presumably due to handover and is back in development now with a different maintainer. Due to this thread being sort of highly ranked in search engines folks (like me) will keep coming in with related-but-not-entirely kinda posts
Yeah sorry my bad didn’t mean it that way. Have been following for a long time, only joined recently to share something I thought could be useful (or discussion-worthy or whatever)
Could you so kindly put a note at the top of the archived repo, or edit the description to say where the development has moved? Potentially adding the reason as you stated.
It’s to the benefit to add reasons when a repo is archived so that users of said repo know where to go.
am I late to the party? I could propose new M3-based designs and, on pastime, implement them with Compose. just need to figure my way out of these effin’ outages, damned Russia…
it kinda hurts to see many great open-source apps adopt a design language that makes them cohesive with each other. core UX will stay largely the same, it’s made well. my only concern is looks.
Hey! I feel the same. And I’m trying to do exactly that. Feel free to check it out in the repo. The dialog box for showing device id qr code is done already and right now I’m upgrading the settings.
The whole situation can easily be confusing, especially if you read the whole topic here, as things were changing quite dynamically. From my understanding, the final conclusion is that everyone eventually agreed to work together on a single Android application under https://github.com/researchxxl/syncthing-android. Alternatively, there is an experimental Android version of https://martchus.github.io/syncthingtray, or you can also run Syncthing from a command line using Termux.
I’ve spent hours going over all 233 comments, discussions in other forums as well as Github.
The highlights of this situation are:
Catfriend1 confirmed his retirement from Syncthing Android development and ownership transfer to researchxxl(#165).
researchxxl made a public announcement to clear up the confusion as well as his goals and intentions going forward (#195).
The original repository got pruned and future development will be carried out in: researchxxl/syncthing-android with help of nel0x(person responsible for Playstore Releases since Syncthing-Fork).
F-Droid & Syncthing developers have confirmed there’s no indication of malice in the new repository for now. Previous commits have not been altered (#141).
Syncthing-Fork builds are still fully reproducible to prevent supply chain attack (#65). For greater safety you can opt to use F-Droid builds as there’s more time between version bumps from upstream code releases to spot any wrongdoing.
The transition wasn’t transparent at first which caused a lot of confusion and mistrust.
Minimal wrapper for Syncthing on Android. Unlike Syncthing-Fork, it does not use Android’s Storage Access Framework to avoid performance degradation. The intention behind this project can be found here.
This one needs more vetting from the community to determinate if the developer is trustworthy.
PLEASE STOP COMMENTING WITHOUT CONTRIBUTING NEW FACTS
Every new comment notifies hundreds of people. Nothing new has been said for past 200+ comments
)