2 days ago I reported about a #security patch having been applied to the IzzyOnDroid F-Droid repo aka #IzzySoftRepo – but I didn't give much details. After it was tested now at the IoD test & staging area, and running smoothly for two days for the public one, I reported back to its author @obfusk that all seems smooth, and she decided to make POC & patch public. You can find the full details at https://github.com/obfusk/fdroid-fakesigner-poc & https://www.openwall.com/lists/oss-security/2024/04/08/8 now. @fdroidorg @eighthave be welcome using it!
1/2
@IzzyOnDroid @obfusk @fdroidorg you just published this wide open, yet before, you wouldn't even send us the POC code that you had? I think you two need to learn what #ResponsibleDisclosure means.
@eighthave PS: Had that issue not been wide in the open for almost a year, giving the impression to be not important, we had of course approached @fdroidorg with a confidential issue first. But that signaled it would be ignored as well. As is https://gitlab.com/fdroid/fdroidserver/-/issues/1056 opened 10/2022, POC available (& linked there) since 1/2023. Affecting reproducible builds. A lot of evil stuff could be injected that way, as was outlined, also in my latest articles. So please don't call *US* irresponsible @obfusk
@IzzyOnDroid @obfusk @fdroidorg Part of the bug was known 11 months ago. The new proof-of-concept shows key details that were not previously known nor reported in the issue. Those were just dumped to the public. We asked for that yesterday, and you didn't send it to us, but withheld it to now publicly dump it. That code was posted to GitHub yesterday: https://github.com/obfusk/fdroid-fakesigner-poc/commits/master/
You could have just sent us that link yesterday before tooting it, that would have been better.
@IzzyOnDroid @obfusk @fdroidorg I see this was reported to #androguard yesterday https://github.com/androguard/androguard/issues/1030
Did you give them any advanced warning?
@eighthave I totally get it that you're not happy with the current situation (for what it's worth, we haven't been for years). But now going to "dig up things" about @obfusk trying to put the blame on her after having ignored her and her advice for so long is not a nice thing to do. Please stop that. This is not about doing dirty laundry in public but about getting long standing issues solved. @fdroidorg
@IzzyOnDroid @obfusk @fdroidorg All I'm asking is for #ResponsibleDisclosure. The tone you sense was my panic as I scrambled to figure out the proof-of-concept to ensure that #FDroid users are kept safe. Signature verification is a key part of that. I cleared my schedule this morning to deal with this.
Thanks to @obfusk to doing the hard work of the proof-of-concept and the patch. I posted my preliminary analysis of the issue on https://gitlab.com/fdroid/fdroidserver/-/issues/1128#note_1852935205
1/2
@IzzyOnDroid @obfusk @fdroidorg They key takeaway is:
If a binary repo maintainer is not careful about where they get their APKs and relies completely on AllowedAPKSigningKeys to verify the APKs, then this is an important issue.
2/2
@IzzyOnDroid @obfusk @fdroidorg That was not directed at you, that was my takeaway from the analysis I posted in the 1/2 post. The TL;DR.
@eighthave Ah – in that case, apologies. Yes, it was the context – and the idea sounded too absurd TBH, especially with AllowedAPKSigningKeys not even existing that long (and I doubt except for @fdroidorg and IoD, any repo uses it at all. @obfusk
@IzzyOnDroid @obfusk @fdroidorg sorry, I guess I should have started a new thread. I'm not so good at the social medias...