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 !
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.
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
@unifiedpush does it default to a certain server?
@charlag Yes, it uses mozilla's one
@unifiedpush open the open? ;D
Really awesome!
@shadowwwind Thanks :)
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 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
@IzzyOnDroid @unifiedpush 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
@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
@IzzyOnDroid @unifiedpush It will be removed for the next release
BTW, I've added the badge for IzzyOnDroid on https://unifiedpush.org/users/distributors/sunup/
@S1m Cool, thanks!
@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, https://codeberg.org/s1m/my-fdroid-repo 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 ?
@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 https://github.com/obfusk/apkrepotool for an fdroidserver replacement for simple repos (just maintain the index, no build etc).
@IzzyOnDroid Thanks ! I'll give a look to all of these
@S1m Nextpush is integrated (and RB, congrats!), will show up with the next sync. Will prepare UP-Example now as well.
@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 https://gitlab.com/IzzyOnDroid/repo/-/wikis/Fastlane for "official locations" (for IoD, any location does, just no symlinks yet).
@IzzyOnDroid Thank you ! I have added the icon to fastlane, and updated links on UP website :)
@S1m I have also replaced the Github links on the app listing by Codeberg ones: https://android.izzysoft.de/applists/category/named/network_push
@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.
So this would replace something like ntfy.sh or NextPush, right?
@Blort Yes, exactly