And to make finding, installing and updating easier, Sunup will become available at #IzzyOnDroid with the next sync around 7 pm. Congrats @unifiedpush – it has the "green shield up", meaning it's reproducible
But if you could get rid of that DEPENDENCY_INFO_BLOCK (a binary blob), that would be great. Easy to do, reach out to us for instructions, which do not fit into a toot – but wait, there are attachments, right? So for your build.gradle, see screenshot.
@IzzyOnDroid @unifiedpush Will do, I've to do it for another app too :)
@IzzyOnDroid @unifiedpush There is one thing I'm not sure about that frosting chunk. It looks like a signed field used by playstore and other anti-virus to control the legitimacy of the application. I don't know how efficient it is but removing that may make the app more "suspicious" for their detecting tools
Wouldn't it be better to control that chunk's content instead of removing it ? If you prefer, we can use a matrix chan for this
@S1m who's talking about Frosting? That's something entirely different, and your APK is not affected by that. I was only talking about dependencyInfo (DEPENDENCY_INFO_BLOCK is a binary representation of that, encrypted with a Google key so it cannot be verified, see e.g. https://android.izzysoft.de/articles/named/iod-scan-apkchecks#blobs). How did you get the idea about Frosting? @unifiedpush
@IzzyOnDroid @unifiedpush Because of this article [bi-zone.medium.com] shared on the other app's issue [codeberg.org], also shared on F-Droid repo [gitlab.com] but I've probably been confused about with the 2 different blocks
@S1m Ah yeah, F-Droid still links to that article about frosting. We've told them multiple times that's something different. They prefer keeping the link, can't be helped… @unifiedpush
@IzzyOnDroid @unifiedpush I see, thanks for the clarification. I don't share my apps on the Playstore, I guess that's OK to remove that block.
On the other side, they are pretty small apps and they are reproducible so everybody can verify nothing suspicious is hidden in this block :)
@S1m @IzzyOnDroid @unifiedpush No one but Google can verify nothing is hidden in there as it's encrypted.
You'd have to audit the code that generates it as well as all the inputs and then verify you get an exact match, since you cannot look at the data from the block itself: it's a completely opaque encrypted binary blob (which means it's not exactly FOSS either).
But you can't currently do that since it's not even reproducible: https://issuetracker.google.com/issues/268071369
At IzzyOnDroid, our scans try to flag what we can: https://gist.github.com/obfusk/a993b1bb54f52e1f6d2f56b1f97b2100
But there are plenty of places to hide something; e.g. F-Droid would not catch this at all since they only flag a handful of specific blocks instead of anything unexpected: https://github.com/obfusk/sigblock-code-poc
@S1m @IzzyOnDroid @unifiedpush Unfortunately, being reproducible doesn't help here since that requires copying the signature to get a bitwise identical APK. So it fundamentally cannot prevent anything being hidden in the signature data itself, only in the rest of the APK.
@obfusk @IzzyOnDroid @unifiedpush You can verify that the application doesn't use this block for anything, no matter what is in it
@S1m @IzzyOnDroid @unifiedpush Can you, practically? Being sure would require auditing the source code of the app *and all its dependencies*. And keep doing that when anything is updated. And you'd still be none the wiser if e.g. *some other app* (or even the OS or something else) uses the block instead of the app using its own.
@obfusk @S1m @unifiedpush "some other app": IIRC, we evaluated that case even. Every app can read every APK installed on the device, so that would be the practical multi-channel thing: Put something into the signing block of one app, use it from another.