It’s good that the situation has been clarified a bit. For me, the main question remains whether the new owner is someone to be trusted, as we’re talking about a fresh account with zero history. This wouldn’t be a problem if we were talking about a third-party project, but Syncthing-Fork is something we officially recommend on the Syncthing website.
5 Likes
This is a very odd way to choose a new maintainer. Why didn’t Catfriend1 archive the repo and announce that he discontinues the app? The successor doesn’t need to get the signing keys, users can decide to export settings from the old app and install the new app.
2 Likes
Anyone can see what will be added to the repository. That is the advantage of open source. Give him a chance.
We should welcome the new maintainer to make an account here in the forums, intro themselves and have a conversation with us, the users.
It’s good to be cautious. Remember the XZ Utils backdoor; the guy did a good job for years before the incident.
I find that this is a strange way to do things, too; also the account and circumstances. We should probably wait for them to communicate a bit more about themselves and the situations.
2 Likes
I guess I’ll just say that as far as maintainer handovers go, this is approximately the opposite of how I’d recommend doing one, in terms of communication and building trust.
12 Likes
There’s no question that the whole process was rather clumsy. It’s also right to be cautious. But that’s why we use open source.
Anyone can see what will be added to the repository.
Remember the XZ Utils backdoor
yes, the one that specifically avoided committing the backdoor to the repository
edit: yup, misremembered, was in the repo but compressed, thanks for pointing that out, the m4 file was missing
Built APKs are already available for download in the new repo. Not implying anything here, it may very well just be a chaotic well-meaning attempt to keep the project in maintenance / available as they described. But there’s more to trust than being able to see the repository.
In case you missed it, XZ Utils is open-source software. It’s also far more ubiquitous than Syncthing.
As far as I know, the backdoor was committed to the Git repository as a test case, and virtually no one noticed it. It even made it into the pre-release packages of some distros. The backdoor wasn’t exposed by someone reading the code; it was uncovered by someone benchmarking performance. We avoided disaster largely through a heavy dose of luck, thanks to him.
I’m not saying this to dismiss a potentially good maintainer candidate; just to highlight the lessons learned from history.
Not entirely true, see the Wikipedia summary:
A modified version of
build-to-host.m4was included in the release tar file uploaded on GitHub, which extracts a script that performs the actual injection intoliblzma. This modified m4 file was not present in the git repository; it was only available from tar files released by the maintainer separate from git.
The release bundle contained the backdoor, but not the git repo itself. Several distro upstream imports however work with release bundles, not git directly.
Some parts of the exploit were included as part of a test case (which was in git) yes, but the whole thing needed several parts to work - including a third-party patch to openssh, which several distros had however - and wasn’t included in git.
2 Likes
and wasn’t included in git.
Sure, but the important lesson from that is that just “being open source” isn’t sufficient to prevent bad actors from finding ways to sneak in unexpected payloads.
I have tremendous respect and gratitude for the Syncthing-fork maintainers, both old and new (having myself burned out on open source projects that got accidentally popular).
But I also think it needs to be unambiguously communicated to them that it is tremendously important that they maintain the trust of users in a project like this. It is not sufficient for the maintainers to not be malicious. They have to make it clear, by the visible signals they send, that nothing suspicious is going on. And they are currently failing in that. This needs public acknowledgement and discussion, so we can all understand how the project will avoid it going forwards.
Much love and respect to all the people I’m slighting here. I know that I’m speaking from ignorance, and I apologize, but we are trusting all our data to this project, so it needs to be beyond suspicion.
10 Likes
Thanks for the correction.
Since I don’t have the skill to audit Syncthing’s Android code, naturally, I would be more afraid than those who do. I could only hope we have enough eyes to track the changes for sufficiently long time.
1 Like
2 new releases have now been cut with built apk’s and archives now without signatures. Who knows if the released APK’s are built from the repo’s visible source code now.
I was using Obtainium to install this which watches for new updates from GitHub URLs. Normally it would have installed these since Github is silently redirecting to this new GitHub account with no other history.
The only reason it did not install these because Obtainium left a couple 404 error notifications while the forwarding was not in effect that I did not swipe away.
I have set it to ‘track-only’ and not install updates. The speed of this ‘take over’ has allowed this to directly install into my device if I was less diligent.
I ran the two patches through gpt-5.1-codex and the findings are below. The notable part being that apk and release signing has been removed. This is not malicious in itself, but it is certainly questionable that a new github account is silently taking over and releasing apk’s of it within hours of semi-publicly speaking in their fresh new locked down repo (only to collaborators).
Across the two handover releases, every visible reference to the old “Catfriend1” stewardship was switched to the new “researchxxl” GitHub account. That includes README badges, issue links, privacy policy, FDroid metadata, Android resource strings, localized Play Store descriptions, build scripts, helper scripts, and wiki pages. Gradle and Android project files now read signing values from local.properties if environment variables are absent, and the version code/name moved to 2.0.11.3. GitHub workflows were also retuned—debug builds are tied to an environment, and releases are now created through a manual workflow_dispatch job instead of automatic tag pushes.
The more significant change in terms of supply-chain confidence is that all of the GPG-based verification tooling was removed. The wiki section that hosted Catfriend1’s public key, the instructions for checking signed checksums, and the dedicated release notes about GPG validation were deleted. Matching that documentation change, the CI release workflow no longer generates SHA256 checksum files nor signs them with the project’s GPG key; completed releases are simply uploaded as unsigned APKs. That means users no longer have a built-in way to verify that an official build matches the source code in the repository, increasing reliance on the new maintainer’s goodwill even though the application’s source itself hasn’t been modified beyond the rebranding.
10 Likes
Yeah for an app that has full filesystem access, it’s unfortunate how little communication there was about this. I would suggest they consider enabling reproducible builds since that would go a long way in building trust. It would allow F-Droid releases to act as a confirmation check to show that that GitHub releases do match the public code (without requiring users install the F-Droid signed variant). The GitHub issues section just redirects to this forum though. And I have no clue how much work it would take.
7 Likes
At this point, it looks like this could end up being a personal solution for someone that relies on the app, but doesn’t want to take on the burden of maintaining it for others to use. Which is understandable. But in such a case, it’s really inappropriate to silently take over the release channels relied upon by many users, without any public communication or even a way to get involved.
I came to the repo to offer help with porting the translations setup from Weblate to the new “home” of the app, but couldn’t even find a way to leave a comment to that effect. Let’s just give it some more time and watch how things develop, with great care not to accidentally update as long as the intentions are so unclear.
2 Likes
Argh, I wasn’t thinking about Obtainium. The combination of github redirects and key handover leading to auto-upgrades is now indeed a problem. And makes wait and see not a viable strategy anymore.
@sedlund Did you check the APK’s release signatures, i.e. that they are the same as @Catfriend1 prior ones? From what you describe I assume yes - just want to double check. I can check myself otherwise in a bit, but want to do some other things myself first.
While I am not saying that I see anything problematic with the releases yet, as calmh and @sedlund pointed out how it happened is definitely weird. I haven’t found a way to contact researchxxl (ticket is locked) - if anyone can, please ask him to get in contact and/or remove these releases from github for now. I am actively looking into ways to improve this situation as soon as possible and will update when I know more (or don’t).
I found two repos with syncthing for Android on GitHub btw. One seems to be a (personal?) maintenance repo for the old official version since that was discontinued: https://github.com/IzumiSenaSora/Syncthing-Android
The other one popped up just after Catfriend1’s departure and contains new Syncthing-Fork releases: https://github.com/heartnn/syncthing-fork
Maybe they can help as well @nel0x ? Both have a lot more history on GitHub.
tl;dr for android users:
No need to switch apps at this time, the current install continues to work and is safe. If you can disable app auto-updates, please do that for now to be on the safe side.
Good news: Had a good chat with @nel0x. He is a collaborator on researchxxl’s repo and just marked those releases as “pre-release”, which prevents the obtainium auto-upgrades. So we are back to no immediate risk for users and we can take it slowly, trying to establish communication and more context. It’s still possible and imo likely that nothing nefarious is going on, just a very suboptimal handover that needs clearing up. There’s no need to go dig for repos on github, the technicalities of continuing to publish an app are not an issue - the open/relevant points are about a possible direct continuation of the existing app (or not), the time/effort that needs to be volunteered to publish an app and the trust in whoever does that. Hopefully we can work something out. If you are interested in helping maintain the app, let us know, other than that imo nothing to do here except if you are a user, to do the above in the tl;dr and every now and then check-in on the status (now and then being more like every week than every hour 
).
Edit: Just FYI/to pre-empty questions here: Looks like F-Droid is building the new tag/release from the redirected repo. This is not an issue, as they are building from source and there’s no indication anything is wrong with that source - at least the last commit was unproblematic.
16 Likes
Apologies, but the tone of your message is a bit strange:
This just sounds like trying to discourage others from trying to find out what actually happen… Why?
I am a long time Syncthing user and use Syncthing-fork on several devices… and very much concerned about the way the “transition” happened - this raises many red flags from security perspective. And then reading your post with the message “close your eyes and don’t look” is quite strange.
I’d say - since this is an Open Source project, any concerned person, not just user - can have something to say about situation here, no need to silence these.
2 Likes
Welcome here @dgcom !
(No one should have to speak in his own defense, that’s why I respond here.)
To begin with, @imsodin’s way of communicating is very direct. His intentions are ALWAYS the best and once one understand the message he conveys, not just the words, things make perfect sense.
Secondly, he is not silencing us, but instead pointing out that the hard facts regarding the state of the repos and history etc is now known, so there is no need for more digging there.
Thirdly, talks are ongoing with @nel0x(who is known here), so we should not have to worry about the future of the SW either. With the caveat that talks are ongoing, of course.
I think the main takeaway here is: Hopefully we don’t have to worry. Wait and see.
8 Likes