fosstodon.org is one of the many independent Mastodon servers you can use to participate in the fediverse.
Fosstodon is an invite only Mastodon instance that is open to those who are interested in technology; particularly free & open source software. If you wish to join, contact us for an invite.

Administered by:

Server stats:

11K
active users

UnifiedPush

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

Summary card of repository Sunup/android
Codeberg.organdroidandroid

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?

@unifiedpush open the open? ;D
Really awesome!

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.

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

MDN Web DocsOpenSearch description format | MDNThe OpenSearch description format can be used to describe the web interface of a search engine. This allows a website to describe a search engine for itself, so that a browser or other client application can use that search engine. OpenSearch is supported by (at least) Firefox, Edge, Safari, and Chrome. (See Reference Material for links to other browsers' documentation.)

@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).

GitHubGitHub - obfusk/apkrepotool: apkrepotool - manage APK reposapkrepotool - manage APK repos. Contribute to obfusk/apkrepotool development by creating an account on GitHub.

@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 gitlab.com/IzzyOnDroid/repo/-/ for "official locations" (for IoD, any location does, just no symlinks yet).

GitLabFastlane · Wiki · IzzyOnDroid / repo · GitLabThe F-Droid compatible repo at https://apt.izzysoft.de/fdroid/

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

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

issuetracker.google.comGoogle Issue Tracker

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

@unifiedpush

So this would replace something like ntfy.sh or NextPush, right?