@nel0x I would like to contribute to the project on GitHub. Are there any plans to add more people to help with improving and maintaining the project?
I read the message differently than how martinleben interpreted it; maybe my interpretation makes more sense to you.
The sentence you quoted is imsodin’s reply to melusine, who was trying to help. imsodin was just pointing out that finding the lost branches isn’t an issue. Also, I noticed that hxtmdev has a fork containing the latest Catfriend1’s commit. I’m sure he has a local copy too.
If the sentence was read out of context, it could cause a misunderstanding. And, of course, you can still reply to this thread; if the intention was to silence, the thread would be closed. Hope that help clear things up a bit.
2 Likes
Has Syncthing-Dotk ever had reproducible builds?
Well, I read this thread from the beginning, the issue with forums like this they do not directly show who replied to whom unless there is a quote.
I strongly believe that everyone here is trying to help, it is just the matter of choosing the right words and I don’t find that specific imsodin’s post good contribution, that’s why I responded here.
I am also watching this issue since I switched to Obtanium some time ago, but now re-thinking this approach because one of my devices was updated to a new, unverified version silently.
I plan to switch Obtanium to use F-Droid repos instead of GitHub because of this.
But overall - I’d rather encourage more users to look at the project and related GitHub bits and pieces - to uncover more details on what happened and alert if there is any malicious activity being detected.
Syncthing-Fork has had reproducible builds since the 2.0.7.0 release, despite what @ImranR98 is implying.
The F-Droid reproducible build documentation says:
Binaries is present in the build metadata.
See metadata/com.github.catfriend1.syncthingfork.yml · 71e31b2f72ae8792d83f26251178fa695b9a7167 · F-Droid / Data · GitLab and syncthing-android/scripts/fdroid/com.github.catfriend1.syncthingfork.yml at cf4714bc9d07d49b7956ad24cb2458aa6e188baa · researchxxl/syncthing-android · GitHub.
2 Likes
In fairness to Obtainium, the signatures do match. Whenever you add an app via Obtainium (regardless of the source), it will only update the app if the signatures match. The trust is based on the signing keys, not the repo.
This seems right to me in theory. Catfriend1 could also have handed over the old repository and keys to a new maintainer. In fact, that would’ve been the sneakier way to do it, as we all might not have been the wiser. Ultimately, any app store is placing ultimate trust in the signing keys and that whomever controls them is trustworthy. The same thing could happen with apps distributed via GPlay (although handing over one’s Google Developer account might feel a bit more significant than handing over one Github repository).
That said, I got the 404 error from Obtainium, did a little digging, got wigged out, and blocked all future ST-Fork updates until things settle down. I’m definitely in the wait-and-see camp as well, since this whole situation seems unsettling. I wouldn’t be as paranoid if it were, like, a weather app, but ST has access to some of the most sensitive files in my life.
Open source maintainers are under zero obligation to all of us, but I do think it’s “the right thing to do” to honestly announce when you’re bailing and give users a heads-up (similar to what happened with the old, original version). Still, I really do appreciate all of the work that Catfriend put into maintaining the app during the last year.
Anyway, my point was more to defend Obtainium’s approach, which I think is reasonable. If the signing keys are compromised, all bets are off—and that’s true with iOS, Android, OSX, and even Windows (granted, with the more centralized app stores, the stores themselves can revoke keys that they think are suspicious, although they don’t seem to do a very good job of that). That’s why supply chain attacks are so potent.
I hope things do settle down, because ST is one of my absolute favorite utilities, and being able to run it on Android is one of my favorite parts of Android.¹ I wish I had the time to contribute. 
¹Although it sounds like the OG app still does work (especially turning off global discovery and relays would help reduce unpatched attack surface), and it seems like we could run ST inside of Termux (or even the new Linux virtual terminal) as a less-elegant alternative.
4 Likes
Syncthing-Fork has had reproducible builds since the 2.0.7.0 release
Ah, that’s great. I didn’t realize.
F-Droid has not finished building/releasing the first release to come out since the switch/handover so I’ll still hold off from installing it just yet. But if that goes well it’s a green light for me.
1 Like
I use Syncthing via Termux and it works fine, but if you want something more similar to the Syncthing-Android app, then there is also https://martchus.github.io/syncthingtray. Android builds are still experimental, but they come from @Martchus, who has been a very long time member of the community.
5 Likes
I also came here with the hope to find clarification… did someone already notice that the google play releases by @nel0x are also signed using Catfriend’s key? How can integrity be assured across updates that the code matches the repository which is now owned by @researchxxl
Hi labtitan, there’s a good chance that it is still documented incorrectly somewhere but no, my releases have always been signed with my own key.
1 Like
@nel0x Well, just download your latest 2.0.9.1 bundle from apk mirror and analyze the signature of base.apk 
. Clearly says Catfriend, no offense intended.
I see, the reason for this lies in how the Google Play app signing mechanism works. As explained (and visible on my repo) all App Bundles I build are signed with my personal signing key, which Google calls Upload key certificate. After they’ve verified it, they strip my signature and re-sign the artifacts themselves (apparently still using the key that Catfriend uploaded a long time ago). After that the per-device APKs can be delivered to the end users.
3 Likes
It’s funny how some FOSS enthusiasts are so similar to each other… 
And once again, I was convinced that Obtainium is more useful than F-Droid, because without Obtainium and the 404 error I got, I wouldn’t have started digging, but would have simply received the update through F-Droid over time.
I also have a habit of not updating anything automatically (except GrapheneOS). That is, if I receive an update for any application, from any source, I always check what has changed, and also quickly check Github/-lab, the community chat (if there is one), etc., and only then do I update manually.
I fully share the concerns of other users regarding trust and the future security of using Syncthing-Fork. Since the latest version of Syncthing-Fork is working perfectly for me at the moment, I am not going to update it, as I have zero trust in the new maintainer who appeared out of nowhere. [ this is not said to offend anyone; it’s just part of my digital hygiene/logic ]
I would like to take this opportunity to add that it is important to support FOSS with money.
For my part, I always ask to add the option of donating in Monero (cryptocurrency), and I am the first to send a donation of $50-100. Thus, I pay for most of the FOSS applications I use on Linux + GrapheneOS (every year), and I pay with great pleasure.
4 Likes
Upon getting the 404 on Obtainium and not being able to read code i uninstalled the last most recent version downloaded from Catfriend1s git…
It seems like that wasn’t necessary having followed this thread.
For an average non code reading safety concerned grapheneos syncthing-fork user which version and from where can i currently download a safe working version?
Thank you all
Obtanium auto updated my Syncthing-Fork so I uninstalled it asap and I went with the last F-Droid release.
I could have gone with the 2.0.11.1 but I read this:
Not sure If this is the right approach so maybe someone can shed some light.
It was manually cancelled.
why?
There is an ongoing conversation, idle for 2 days now: https://github.com/researchxxl/syncthing-android/issues/16
1 Like
Also that repo has a closed issuetracker which is not great as import of syncthing-fork configs fails
1 Like
Why isn’t the new maintainer opening up the issue tracker for all comments? it’s not a youtube comment section, what are they scared of? I hope either they either open it up for all, or someone more known forks it. I’d trust Onedrive over a random with no communication from the original maintainer
4 Likes