Skip to main content


Want to try a new distributor ? Nothing to setup, you just need to open the app and grant the requested permissions. It follows the last version of the UnifiedPush specifications: Sunup !

codeberg.org/Sunup/android

#UnifiedPush #Android

This entry was edited (3 weeks ago)

IzzyOnDroid ✅ reshared this.

in reply to UnifiedPush

Most of the applications supporting UnifiedPush should work without any issue. But a few may break, so if one doesn't work, let us know: the application may not be following the last specifications.
in reply to UnifiedPush

Regarding Matrix, a workaround has been implemented until webpush is supported by their specifications. Element-X has a patch going on to fix the default gateway (but Schildinext works), all other clients already supporting UnifiedPush should work

#Matrix #Element #Schildichat

in reply to UnifiedPush

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 :awesome:

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.

#reproducibleBuilds

UnifiedPush reshared this.

in reply to S1m

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

This entry was edited (3 weeks ago)
in reply to S1m

@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. android.izzysoft.de/articles/n…). How did you get the idea about Frosting? @unifiedpush
in reply to IzzyOnDroid ✅

@IzzyOnDroid Because of this article shared on the other app's issue, also shared on F-Droid repo but I've probably been confused about with the 2 different blocks
in reply to S1m

@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
in reply to IzzyOnDroid ✅

@IzzyOnDroid 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 :)

in reply to S1m

@S1m @IzzyOnDroid 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: issuetracker.google.com/issues…

At IzzyOnDroid, our scans try to flag what we can: gist.github.com/obfusk/a993b1b…

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: github.com/obfusk/sigblock-cod…

in reply to Fay 🏳️‍🌈

@S1m @IzzyOnDroid 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.
in reply to Fay 🏳️‍🌈

@obfusk @IzzyOnDroid You can verify that the application doesn't use this block for anything, no matter what is in it
in reply to S1m

@S1m @IzzyOnDroid 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.
in reply to Fay 🏳️‍🌈

@obfusk @S1m "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.
in reply to S1m

@IzzyOnDroid Nevertheless, this block is about the dependency list, so its absence may be used to flag potentially suspicious app, don't you think ? I wonder if there isn't another way to simply control that blob
in reply to S1m

@S1m Nobody but Google can read it. So if you're afraid it would be used to flag your app, that could only be done by Google, where you upload the AAB I guess. As we only take the APK, you could leave the blob in with the AAB then. @unifiedpush
in reply to IzzyOnDroid ✅

@IzzyOnDroid It will be removed for the next release 👍

BTW, I've added the badge for IzzyOnDroid on unifiedpush.org/users/distribu…

in reply to IzzyOnDroid ✅

@IzzyOnDroid I've never really looked into IzzyOnDroid repo, that's pretty cool :)

I'd love to use your repository with an option to filter only "FOSS and RB apps" (or even with target SDK>XX). I think all the metadata required is there, so that must be a client thing to be implemented

I now have some questions 😄

Is it worth adding NextPush and UP-Example to your repo ? 3 MB each, but they are already in the main F-Droid repo

What do you think about adding an open search xml to the repo ?

I also wonder if I can use some of your scripts to maintain a minimal f-droid repo (See this, codeberg.org/s1m/my-fdroid-rep… but it is broken right now, because of an outdated dependency in F-Droid container), I am not sure how what the different scripts do. Do you have documentation about how things run ?

in reply to S1m

@S1m Full answer gets too long for a 500 char toot… Yes, client support is planned (Droid-ify & NeoStore, we work together there). Yes, I can add the other two apps (no prob with the overlap). Be welcome to open an issue for OpenSearch, though I'm not sure when we'll find time for it. And "simple repo setup" is on our todo as well. You might wish to take a look at github.com/obfusk/apkrepotool for an fdroidserver replacement for simple repos (just maintain the index, no build etc).
@S1m
in reply to S1m

@S1m Nextpush is integrated (and RB, congrats!), will show up with the next sync. Will prepare UP-Example now as well.
@S1m
in reply to IzzyOnDroid ✅

@S1m UP-Example is also RB and prepared for the next sync. Fastlane lacks an icon.png there, I locally added the one from app/src/main/ic-launcher-playstore.png (you can simply copy that to fastlane). I only picked the "main" variant; if you want the other one with IoD as well let me know, but then we should have a separate fastlane tree for it, see gitlab.com/IzzyOnDroid/repo/-/… for "official locations" (for IoD, any location does, just no symlinks yet).
@S1m
in reply to IzzyOnDroid ✅

@IzzyOnDroid Thank you ! I have added the icon to fastlane, and updated links on UP website :)