On Fri, 23 Jul 2021 11:05:59 -0300 Adonay Felipe Nogueira via Replicant <replicant@osuosl.org> wrote:
> Em 16-07-2021 12:05, Denis 'GNUtoo' Carikli escreveu: > > Are they supposed to be used as-is or are they supposed to be > > integrated in the Android distribution somehow? > > As far as I have researched, they either require the system > distribution to support signature spoofing ([1]) or they use the > “package” and “android:name” attributes on their AndroidManifest.xml > (the so called application/activity/service/intent identity or > “true/system names”) in a way to replace their corresponding Android > originals (to get a proper idea, clone some of their source > repositories and search for an *extended* regular expression such as > “com(\.google)?(\.android)?”). > > However, I don't know if there are any other requirements. Thanks. So it's something like f-droid privilege extension. That could be integrated if there is some interest and that people send patches for that. We'd probably need to build it from source in that case to make sure that it can be built and that we ship corresponding source code with the releases. > > At least that functionality is not suited for distributions that > > follow the Free System Distribution Guidelines (FSDG)[2] because > > "The distro must contain no DRM, no back doors, and no spyware."[2]. > > Interesting take. > > I don't know if the FSF or the reviewers of FSDG-fit distros consider > sending Push Notifications information to a pre-defined set of > third-parties an infringement of that section of the FSDG, if the core > of the issue is just that it would be sending it to a set of > centralizing parties such as Google or, if Push Notifications itself > is to be considered a problem (since the concept basically involves a > third party storing and spying on the messages sent to the client > 24/7 just for the sake of power saving). In any case, I do recognize > that this is a good argument. I'll open a discussion on the review > work group to raise and question these points. I guess that what typically happens is that the software is patched to be FSDG compliant in general so I'd suppose that it would be the same for spying though I don't have examples in mind to check for spying. In the Parabola blacklist (https://git.parabola.nu/blacklist.git) most of the software mentioned there seems to be blacklisted for freedom reasons (and often replaced by free versions). Many of the packages that were originally problematic are also probably just patched and not in that list. As if upstream is notified, I've no idea. I personally try to work with upstream when working on Parabola at least, but I guess that it takes more time in the short run (and might save time in the long run assuming that local patches don't accumulate when there are less patches). I also tend to do it more when I already know how to contribute patches to the upstream project. > > That would be interesting but I've no idea of the requirements of > > the free software directory. > > Mostly they are the same as the FSDG itself. Nice. In that case I probably need to make sure it can be built in an FSDG distributions at least. Then I could try the GNU/Linux-libre for the issue of the apk being shipped that is built differently if it's somehow not reproducible. I've looked a bit closer at RepWifi and it uses ant as the build system, so it's probably even compatible with the Replicant 4.2 SDK. I don't recall if we ever built it in Replicant or if we always shipped the APK from f-droid. > I'm no longer a reviewer myself, but back when I used to do those, an > eligible entry would have all its dependencies either on the Directory > or on the repositories of FSDG-fit distros (to simplify: any > dependency of any level or any strength, except “system libraries” > per GPL definition). ok. We should probably see with GNU/Linux-libre and/or the Free software directory how to handle that for Android as there is way more risk of finding problematic software in Android than in GNU/Linux due to how things are packaged (it's much easier to check a package definition than the Replicant source code, even if there are still mechanism to generate licensing information somehow in Android). > If the release is historical (see [2] to know what I mean) we might > still be able to add it to the Directory. Here I'm not sure that historical applies for Android in the same way as older Android versions tend to stay around for very long, and you can also use older build systems to build applications that run on more recent Android versions. Denis.
pgpGsrlPU9D0h.pgp
Description: OpenPGP digital signature
_______________________________________________ Replicant mailing list Replicant@osuosl.org https://lists.osuosl.org/mailman/listinfo/replicant