A commenter posted:
Any ideas why the comment and suggestions posted by imsodin, are being completely ignored by researchxxl?
researchxxl posted:
I totally understand people out there like to get something more which I do not provide because I do not have anything more atm for you
Absolutely baffling.
I am steering clear of anything researchxxl touches. They clearly don’t understand and/or care what the concern is.
While I do share your bafflement (also in regards to the whole handling of the handover), I think they might actually be correct in saying:
I do not have anything more atm for you
I don’t think they can currently do something to really build trust.
The trust relationship between the original app maintainer and the community has been built over time by means of nobody purporting to have been exploited using the data stored via this app (and possibly also knowing the actual person involved - I don’t know that, actually).
Whether that was ever a reasonable way to build trust instead of watching and understanding every commit that went into the app is a matter of almost philosophical debate.
What we can certainly agree on is, that “having the signing key” is not enough to establish trust. But let’s assume @Catfriend1 would now come out of the woods and confirm the voluntary handover of the key… would we trust them? Or would we rather assume, given what we saw, that a threat actor might exert leverage on them?
I agree with everybody who said it, that the original app maintainer doesn’t owe us anything. Yet that means we are now in a situation where no trust is present whatsoever. That is not meant to sour the possibly good intent of the new developer but it would have made sense for them to convince the original app owner of the value of a more public handover, while they had contact with them.
There’s also, I think, a lesson to be learnt for the Syncthing team here… it might have made sense to built a stronger relationship to the original maintainer in terms of accountability. Read as:
We are extremely happy that you contribute this app to the syncthing ecosystem, but the moment you use the word syncthing and the logo of syncthing in your app, let’s handle the development in the following way:
- the syncthing teams gets administrative access for the syncthing-fork repository (possibly via a github org)
- the friendly maintainer develops the app within the bounds of that organisation
- the syncthing team retains the permission to withdraw or modify code/releases
Would this have been the case, the original trust anchor would have been the syncthing development team and a handover of the project would have looked very differently. I do realize though, that the syncthing development team, by doing that, would have also opened up themselves to possible betrayal of that trust by that developer and thereby a loss of trust in the overall project. Which is where personal trust between human beings comes into the picture again. And also THAT personal trust is no absolute guarantee that nothing will go wrong there.
But now I’m completely digressing… in the end, trust is a timid fawn, isn’t it?
Please take all of the above with a grain of salt and treat it as what it is: just my personal reflections regarding the situation. For the moment, I have disabled automatic F-Droid updates and whether I will ever enable it again is something I cannot yet say for myself.
Cheers Thomas
This is where I’m at with the new changes. I don’t suspect malice, but it will take time for the new maintainer to prove themselves. Until then, we watch how they handle the project. If they make useful updates, and we can see nothing nefarious in them, it might be worth updating. In time, trust builds, and we can all go back to automatic updates.
Hi all,
I digged a bit into what actually happened to the commit history. So for those who want to verify themselves what changed, here is some info.
TLDR: The commit of F-Droid’s 2.0.11.2 release is still in the new repo history.
I checked the lastet F-Droid (com.github.catfriend1.syncthingfork) builds before the downtime event, which should be 2.0.11 from Nov 10 and 2.0.11.2 from Nov 11 (correct me if I am wrong; I myself had 2.0.11.2 installed when I noticed the repo was gone and then this thread started Nov 13).
*See link for 2.0.11.2 and change the last digit; it does not allow me to post more links.
New Github repo: researchxxl/syncthing-android
nel0x’s fork on Github: nel0x/syncthing-android
Therefore, if one wants to trust F-Droid releases up to 2.0.11.2, I would recommend reviewing changes since then for releases after this, and make sure that the versions you install correspond to the reviewed ones (e.g. by checking F-Droid’s build log, as above).
For example, comparing F-Droid releases 2.0.11.2 and 2.0.11.3: https://github.com/researchxxl/syncthing-android/compare/34e85735c10d030ae0dd14526fe9db5523f8da9…cf4714bc9d07d49b7956ad24cb2458aa6e188baa
As you can see, these changes only include:
If anyone has any other trustworthy sources about what the latest commit SHAs for the releases before the incident were, please share!
Hope this helps.
Thank you for your efforts, @Lobi. A little earlier in this thread our friend sedlund did a similar analysis. But still, thank you very much for contributing 
Since I got scolded from being out of topic, I will only post the gist of my message here, with the rest in my github repo for sources and elaboration: https ://github . com/Adhjie /Adhjie-Discussion /discussions /22#discussioncomment-15134447 @nel0x @Martchus
tl;dr If it’s too big of an undertaking, right now; should I export import to nel0x version
(seems like only the google play exist, so gplay is from syncthing android official, syncthing-android is a fork of catfriend1 but no release yet, is it possible to fork syncthing gplay to syncthing android without the gplay restricted code added-in, thus making nel0x/syncthing-android a fork of nelox/syncthing gplay from syncthing/syncthing?)
or Martchus version?
With the warning on Martchus docs (caveats on android version), I’m gonna use the nel0x one for now, sorry for the weird synchronize term, the github org and lovelaceAV with maintainTeam-Hypatia exist but I haven’t got the time to compose the full message here, if all of this are too complex, just take it easy nel0x, Martchus, and other syncthing contributors.
my wall of text is my way of expressing my thanks (this is just how I type message daily), I’ve been using syncthing for a long time, like catfriend1 said, it is a daily driver of my android, computer files and folder sync. I’m not ready to move to rsync gui, or foldersync closed source version, so I’m gonna go with nel0x and wait for another update of the .apk as usual.
Again, thanks to all the contributors and ideas donors, I could only watch and spread the words as a user, only an autodidactic operator here, no programming experience on my ends. best regards, adhjie.
Before I got scolded again, should I just made a new forum thread about “Which syncthing-android to use now after catfriend1 disappearance, nel0x’s, Martchus’, or other maintainers’ versions?” or this message is still on topic?
I’ve browsed a lot of forums for help by reading threads, but first time talking here besides on the 2.0 migration thread, so if I’m wrong, just tell me the right direction to improve on it, please.
Sorry for double posting, but @ nel0x, is syncthing google-play .apk updated from github compatible for export import from catfriend1 syncthing-android last version?
To answer 1-3, I hope the following makes it clear:
Is there any way for end users to be sure that version 2.0.11.2 on F-Droid the is exactly the same code as it was intended by @Catfriend1? In other words: it hasn’t been altered already?
https://github.com/Catfriend1/syncthing-android.git according to the F-Droid log, whereas for 2.0.11.3, the log mentions https://github.com/researchxxl/syncthing-android.git.5.+6. I cannot answer; generally you’ll have to check the changes yourself as I described in my post (which is difficult as a non-developer) or find someone you trust who checks it.
A little nitpick here because I don’t think this is entirely correct. The way I see it (and please, do correct me if you spot an error), the repository has been gone and reappeared.
That means at this point, there is the theoretical possibility, that the git history has been rewritten and malicious code could have been introduced.
Unless you verify the commit hashes in each repository (old + new) and each of them across the entire history matches, there is the possibility of rewritten git history (that assumes, that you have a checkout of the old repository before it changed owners). That being said: the easier way would very likely be to reproducibly build (just as F-Droid does it) the 2.0.11.2 release from the new repository. If the build artifact matches the one of 2.0.11.2 that is currently released in F-Droid, you can be sure the history up to this point has not been meddled with.
Cheers Thomas
Not qualified to answer your question from dev-POV, but what I did after catfriend1 is gone, is to migrate to nel0x syncthing android gplay version until this fork gets updated or I understand how to migrate from nel0x or catfriend1 version to Martchus’ syncthingtray android version.
This needs video guide but I’ll just continue this bit in Martchus GitHub issue, since it’s OutOfTopic here.
One more source of truth could be the Weblate repository which was automatically synced with each commit from the one on Catfriend1’s GitHub. There was an alert on it when the pull first failed and I think it could be frozen at that point, not redirected to the fork of researchxxl. Either way, the repo could be cloned and checked for commit hash equivalence. And there should be a history of pulled commit hashes somewhere in the Weblate interface.
I don’t have the time currently to check on that myself. If I ever do, I will compare to my most recent local clone as well. So at least we know what points in history could be a base for trusted continuation.
A git commit hash is based on the contents of that commit and the hash of the previous one. This means that if one commit hash is the same between two clones it guarantees the entire history up to that point is identical.
That’s not how git works. You can just verify a single commit hash you are interested in to ensure it matches what you expect. The reason for that is:
For
git, the fundamental data unit is a commit. Each commit object contains the hash of its parent commit(s). Changing an old commit would change its hash, and thus invalidate the hashes of all subsequent commits that reference it. This creates a cryptographically secure, historical chain (or Directed Acyclic Graph - DAG) of changes.
There is no way to change something in the past without affecting subsequent commit hashes, unless you found a hash collision; that would be pretty big news on its own.
Another practical reason that changing past tags won’t be an issue is that F-Droid has very limited resources, running on a tight budget. They only build the latest tagged release.
For example, look at this KeePass DX version history (another great software, btw):
Version 4.2.2 (147) isn’t available on F-Droid. This is because while it was queuing for a build, Version 4.2.3 was released just before 4.2.2 started building, causing F-Droid to skip the version. Naturally, they also don’t rebuild any retagged changes in the past versions.
Overall, I think what Lobi said is good enough for the intended audience.
A git commit hash is based on the contents of that commit and the hash of the previous one. This means that if one commit hash is the same between two clones it guarantees the entire history up to that point is identical.
Mea culpa! I forgot this entirely. What a blunder 
. Please edit my original post by striking out my remark, if you so wish (because I’m not allowed to edit the post myself anymore).
I haven’t checked this for a long time, so I checked what’s going on with git and SHA-1. Here’s an LWN article from 2022 regarding the status of the git SHA-1 to SHA-256 migration: Whatever happened to SHA-256 support in Git? [LWN.net] (as always on LWN, reading comments is also enlightening)
It seems by now git itself is able to use SHA-256 hashes (just tested this locally) but the work for interoperability between SHA1 and SHA-256 in the same repo has not been finished. Just this November, further changes have been incorporated into git 2.52.0 (ctrl+f: “SHA1”) and there’s still work left to do.
That being said: I’m explicitly not saying that I think the above is related to what we’re seeing here. My cryptographic expertise is non-existant, when it comes to the question of whether it’s currently feasible to meaningfully rewrite git history.
I was just curious for the sake of argument, because by now my brain is trying to solve the puzzle of “OK, let’s assume this was an attacker, could they have gotten through with this or not, given the infrastructure and software involved” - just for fun.
Cheers Thomas
Github doesn’t support sha256 git.
I just noticed that @nel0x created a new syncthing-fork repo with this statement:
Syncthing-Fork was previously developed and maintained by Catfriend1. As they seem to no longer be actively maintaining the project, I will try to continue its maintenance - not just the Play Store releases but the entire app going forward. Thank you Catfriend1 for building and sharing this amazing project and all the effort you put into keeping Syncthing available on Android!
Edit: and just a few minutes ago this post
Thank you very much!
This is good news. But moving forward, how is this fork going to get published on F-Droid? Is it going to have a new name, e.g. syncthing-nel0xian?
We are planning to publish simply as Syncthing, without personal branding or suffixes.
@nel0x are there any missing features in the Play Store version vs Github or F-Droid releases? For people who use the Google Play Store anyway, would you recommend that version over an Obtainium install?
And thank you so much for picking up this work! 
Thank you for taking the initiative! One thing that may be good going forward is switching to a new app ID for your fork. Currently the app ID is still com.github.catfriend1.syncthingfork - Catfriend1 is no longer involved, and this is also the same ID as is used by researchxxl, so it causes version conflict.