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 github.com/obfusk/fdroid-fakes & openwall.com/lists/oss-securit 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 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 gitlab.com/fdroid/fdroidserver 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: github.com/obfusk/fdroid-fakes

You could have just sent us that link yesterday before tooting it, that would have been better.

@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 . The tone you sense was my panic as I scrambled to figure out the proof-of-concept to ensure that 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 gitlab.com/fdroid/fdroidserver

1/2

Follow

@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

@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 android.izzysoft.de/articles/n 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

@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

Sign in to participate in the conversation
Librem Social

Librem Social is an opt-in public network. Messages are shared under Creative Commons BY-SA 4.0 license terms. Policy.

Stay safe. Please abide by our code of conduct.

(Source code)

image/svg+xml Librem Chat image/svg+xml