Hans-Christoph Steiner @eighthave@librem.one

@cratermoon @timbray sounds worthwhile to me, there are so many compression libs out there

@WPalant Because the submitter deleted their account as a response to the review, I think it could be an deliberate attempt to insert the vuln. Plus all the attention from random new accounts. If it had been a normal review process, I could see how it could have been an honest mistake. But that scenario also makes it more attractive to the attacker, since making a mistake there is quite plausible, and could serve as an easy cover story.

@WPalant Ironically, it could be because I was so aware of the crappy state of things that I caught this. The author of the SQL code was no longer involved. I suck at SQL but was well aware that string concat to build SQL queries is a bad idea. So I was terrified to merge any changes to the SQL without really confirming them.

In any case, we've since replaced all that crazy code with libraries that provide much more protection.

@Optional clear communication definitely suffers when maintainers are overloaded, stressed out and feel ganged up on. I think that's another key takeaway from this current incident. For a well resourced actor, it is not too hard to social engineer themselves into a trusted position when projects get into that position. That happens all too often, unfortunately.

@atrus @joeyh I think a more useful and realistic takeaway from the #xz #backdoor is that build systems should be clean, direct, simple, and easily readable. A key part was the m4 code in the build system that read the payload from the obfuscated test file. If the build system was easy to read, then it would have been a lot harder to do that.

Three years ago, #FDroid had a similar kind of attempt as the #xz #backdoor. A new contributor submitted a merge request to improve the search, which was oft requested but the maintainers hadn't found time to work on. There was also pressure from other random accounts to merge it. In the end, it became clear that it added a #SQLinjection #vuln. In this case, we managed to catch it before it was merged. Since similar tactics were used, I think its relevant now

https://gitlab.com/fdroid/fdroidclient/-/merge_requests/889

@setiathome @kuketzblog @IzzyOnDroid Leider nicht, aber wir haben das selber entdeckt. Ich verstehe nicht was "LibraryCheck" genau ist. F-Droid issuebot benutzt fdroid/suss für non-free libraries, Exodus ETIP für Tracking, und @IzzyOnDroid hat selber iod-scan-apk.php entwickelt als Teil von issuebot. Was ist übrug?

@joeyh Doesn't git have a length field for each blob? That would prevent lots of kinds of abuse. Most of the checks require `git fsck` though, and that isn't run by default. I recommend requiring it in each machine's global git config, e.g. git config --global transfer.fsckObjects=true

@atrus @joeyh I agree that is a good approach, and I try to do what whenever possible. Sometimes it is really time consuming to do that though.

@FritzAdalis It is true, a couple of contributors did quit. I'm happy to see they are still working on Android free software and wish them well. From what I've seen in the past four months, #FDroid has completed a major overhaul of the repository UX in the client (v1.19 and v1.20), launched F-Droid Basic to track the latest targetSdkVersion, and upgraded the buildserver to Debian bookworm. Plus half of the board has completed their first term, and we have promising new candidates. More to come!