Hans-Christoph Steiner @eighthave@librem.one

@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!

@taketwo I would love to see a leak of the GMS certification process, GMS Test Suite (GTS) and related policies. Some of the things that it covers can be gleaned from the websites of companies that provide GMS certification as a service, for example https://www.hexnode.com/blogs/gms-certification-is-it-really-necessary-for-android-devices/

@taketwo I'm not a lawyer, so I don't know if it violates the DMA. But I can say that the facts are pretty clear and they do not support Google's claim made at the DMA compliance workship. Google requires OEM pass "GMS Compliance" aka "GTS" which reviews all apps the OEM includes by default, e.g. an app store.

@santiago @ilumium I also believe that's true. The mobile apps are the key way to keep the product's (e.g. the users) eyes staring at screens so they can serve ads to them. Ads are hooked into Google's Android offerings as well. If they lose market share there, they lose ad revenue.

@researchbuzz 10% of turnover sounds high, but consider that Apple and Google are making at least 40% profit margins on their mobile platforms. So EU take 10%, then they still have 30% profit margins, which is still absurdly good. It is no wonder they are fighting the DMA.