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 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.
@IzzyOnDroid @obfusk @fdroidorg sorry, I guess I should have started a new thread. I'm not so good at the social medias...
@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
@eighthave Pardon me? Not done yet with blaming? Now it's sloppy security on my end? "relies completely": did you ignore all my messages to you the past weeks? Including the blog posts at Kuketz and especially https://android.izzysoft.de/articles/named/iod-scan-apkchecks outlining what security measures were just put into place at my repo *ADDITIONALLY* to those already in effect for years – which are still mostly missing at your end? So my key takeaway again is you don't listen, as so often in the past, sorry. @obfusk @fdroidorg